TDD 법칙
- 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
- 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
- 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
깨끗한 테스트 코드 = 가독성
- DSL(Domain Specific Language): 도메인에 특화된 언어. 테스트 코드 작성 시 잡다하고 세세한 테스트 구현 코드를 숨기는 DSL을 만들어 테스트 코드 가독성을 향상 시킬 수 있다.
좋은 방법인 것 같은데 개발 공수가 좀 들 것 같다. 회사 테스트 코드의 경우 모든 테스트에 공통적으로 적용되는 setup, teardown 로직의 경우 beforeEach, afterEach를 사용해서 분리하긴 하는데 좀 더 가독성을 향상 시킬 수 있을지 고민해 봐야 겠다.
테스트 당 개념 하나
- 테스트 당 assert 하나만 사용할 수 있으면 좋다.
- 중복 코드가 많이 발생할 경우에는 assert를 늘릴 수 밖에 없지만 이 경우 단일 개념이 유지되도록 한다.
F.I.R.S.T.
- First: 테스트는 실행 속도가 빨라야 한다.
얼마전 동료 개발자분과 테스트 시간이 길어지는 부분에 대해 해결 방법을 이야기 했는데 쉽지 않은 부분인 것 같다. 프로젝트의 볼륨이 커질수록 테스트 코드는 늘어나고 총 실행 시간은 길어질 수 밖에 없다. 테스트를 Parallel로 돌리는 방법으로 개선되긴 했는데 앞으로 더 고민해 봐야하는 부분인듯.
- Independent: 각 테스트는 독립적이여야 한다.
- Repeatable: 테스트는 어떤 환경에서도 반복 가능해야 한다.
- Self-Validating: 테스트는 boolean 으로 결과를 내야 한다.
- Timely: 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.
내 생각
TDD는 항상 해야지 하다가도 약간만 마음이 급해지면 포기하게 되어서 항상 아쉬운 부분이다. 그래도 이 장을 읽으면서 지금 회사에 입사하고 배운 내용들이 많이 나와서 좀 뿌듯했다. 다음 스프린트에서는 꼭 TDD로 개발해 봐야지.
