테스트 코드 필요성, 7원칙, FIRST 원칙

[ 테스트 코드 도입을 기피하는 개발자에게 보여줄만한 글 ]

설마 아직도 테스트 코드를 작성 안 하시나요?

 

[ 위 글을 보면서 기억남는 부분 & 기억해야할 부분 ] 

• 테스트 코드 작성에 너무 오래걸린다고 생각이 들면, 
  처음 코딩 배울 때, 코드 한줄 작성하는데 얼마나 많은 공부가 필요했는지 기억해보라.
  
  
• 디자인 패턴으로 열심히 비지니스 로직과 UI로직을 분리하는 이유 중 가장 큰 이유는 테스트 가능 & 용이성이다.
  UI 테스트는 어렵다. 하지만 비지니스 로직을 테스트하는 것은 포기하지 말것.
  
  
• 아래 나오는 [ 테스트7원칙 ], [ F.I.R.S.T원칙 ]을 체크하면서, 테스트 코드를 작성해볼 것.

[ 소프트웨어 테스트 분야에서 40년간 발전된 테스트 7원칙 ]

• 테스팅은 결함의 존재를 보여주는 것이다.
• 완벽한 테스트는 불가능하다. ( -> 기획서에 나와있는 핵심 비지니스로직들을 중점으로 테스트할 것.)
• 테스트 구성은 가능한 빠른 시기에 시작한다.
• 결함은 군집되어 있다.
• 살충제 역설(Pesticide Paradox) — 비슷한 테스트가 반복되면 새로운 결함을 발견할 수 없다.
• 테스팅은 정황에 의존적이다.
• 오류 부재의 오해 — 사용되지 않는 시스템이나 사용자의 기대에 부응하지 않는 기능의 결함을 찾고 수정하는 것은 의미가 없다.
  
  

[ 단위 테스트 F.I.R.S.T 원칙 ]

• Fast — 유닛 테스트는 빨라야 한다.
• Isolated — 다른 테스트에 종속적인 테스트는 절대로 작성하지 않는다.
• Repeatable — 테스트는 실행할 때마다 같은 결과를 만들어야 한다.
• Self-validating — 테스트는 스스로 결과물이 옳은지 그른지 판단할 수 있어야 한다. 특정 상태를 수동으로 미리 만들어야 동작하는 테스트 등은 작성하지 않는다.
• Timely — 유닛 테스트는 프로덕션 코드가 테스트를 성공하기 직전에 구성되어야 한다. 테스트 주도 개발(TDD) 방법론에 적합한 원칙이지만 실제로 적용되지 않는 경우도 있다.