테스트 주도 개발 방법론은 제품의 기능 구현을 위한 코드와 별개로, 해당 기능이 정상적으로 움직이는 지 검증하기 위한 테스트 코드를 작성하고, 이를 통해 실패할 경우, 테스트를 통과하기 위한 최소한으로 코드를 개선한다. 최종적으로 테스트에 성공한 코드를 리팩토링하는 과정을 거치고 나서야 실제 코드로써 동작된다.
단위 테스트
단위테스트를 작성해야 하는 이유는 정말 많다. 그 중 몇 가지 핵심적인 이유들은:
1. 코드를 수정하거나 기능을 추가할 때 수시로 빠르게 검증할 수 있다.
2. 리팩토링 시에 안정성을 확보할 수 있다.
3. 개발 및 테스팅에 대한 시간과 비용을 절감할 수 있다.
단위 테스트를 작성하지 않은 코드들은 테스트를 작성하지 않은 코드들보다 버그가 있을 확률이 높은데, 문제는 통합 테스트 (수동 테스트) 를 진행하는 경우 그 비용이 너무 크다는 것이다. 예를 들어, 어플리케이션을 직접 실행하면서 드는 캐시, 데이터베이스 등 외부 컴포넌트들과의 연결 등, 부가적인 시간이 들기 때문이다.
따라서 개발 및 테스팅에 대한 비용을 줄이기 위해 단위 테스트를 작성해야 한다.
좋은 테스트
테스트를 무작정 하는 것 보다는 좋은 테스트를 작성하는 것이 중요하다. 좋은 테스트는 다음 5가지 규칙, FIRST 규칙을 따른다.
1. Fast: 테스트는 빠르게 동작하여 자주 돌릴 수 있어야 한다.
2. Independent: 각각의 테스트는 독립적이며, 서로 의존해서는 안된다.
3. Repeatable: 어느 환경에서도 반복 가능해야 한다.
4. Self-Validating: 테스트는 성공 또는 실패로 bool 값으로 결과를 내어 자체적으로 검증되어야 한다.
5. Timely: 테스트는 적시에, 즉 테스트하려는 실제 코드를 구현하기 직전에 구현해야 한다.
테스트 주도 개발 (TDD)
테스트 코드를 먼저 작성하는 개발 방법론은 테스트 주도 개발로 많이 불린다. 이 경우 프로덕션 코드보다 테스트 코드를 먼저 작성하는데, 그 이유는:
1. 깔끔한 코드를 작성할 수 있다.
2. 장기적으로 개발 비용을 절감할 수 있다.
3. 개발이 끝나면 테스트 코드를 작성하는 것은 매우 귀찮다. 실패 케이스면 더욱 그렇다.
테스트 주도 개발의 궁극적 목표는 깔끔한 코드를 작성하는 것이다. TDD의 개발 단계 중 리팩토링이 있는데, 이 과정을 거치면서 중복된 코드들은 제거되고, 복잡한 코드들은 깔끔하게 정리되게 된다.
또한 테스트를 처음 작성할 때는 귀찮고 개발이 느리게 된다고 느낄 수 있겠지만, 실제로는 장기적으로 봤을 때 반드시 개발 비용을 아껴주게 되어있다.
마지막으로, 만약 프로덕션 코드가 먼저 작성되어 있다면 이후에 테스트 코드를 작성하는 과정은 너무 귀찮기 때문이다. 왜냐하면 테스트 코드는 성공 케이스 뿐만 아니라 실패 케이스까지 작성해야 하기 때문에, 작성해야 할 테스트의 갯수는 해당 함수에서 발생 가능한 모든 경우들이며, 이미 개발이 완료되었다는 심리적 요인 때문에 테스트를 작성하는 것이 꺼려지기 때문이다.
그 중에서도 실패 테스트부터 작성해야 한다. 즉, 순차적으로 실패하는 테스트를 먼저 작성 후, 오직 테스트가 실패할 경우에만 새로운 코드를 작성해야 한다. 그리고 중복된 코드가 있으면 제거를 한다.
테스트 주도 개발 방법 및 순서
1. 실패하는 작은 단위 테스트를 작성한다. (처음에는 컴파일조차 되지 않을 수 있다)
2. 빨리 테스트를 통과하기 위해 프로덕션 코드를 작성한다. 이를 위해 정답이 아닌 가짜 구현 등을 작성할 수도 있다.
3. 그 다음의 테스트 코드를 작성한다. 실패 테스트가 없을 경우에만 성공 테스트를 작성한다.
4. 새로운 테스트를 통과하기 위해 프로덕션 코드를 추가 또는 수정한다.
5. 1~4단계를 반복하고 실패/성공의 모든 테스트 케이스를 작성한다.
6. 개발된 코드들에 대해 모든 중복을 제거하며 리팩토링한다.
출처
https://mangkyu.tistory.com/182