[Clean Code 정리] TDD

TDD(Test Driven Development)

1) TDD 법칙 세 가지

- 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.

- 컴파일은 실패하지 않으면서 실행이 샐패하는 정도로만 단위 테스트를 작성한다.

- 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

2) 효과

- 테스트 코드와 실제 코드가 함께 나올 뿐더러 테스트 코드가 실제 코드보다 불과 몇 초 전에 나온다.

- 실제 코드를 사실상 전부 테스트하는 테스트 케이스가 나온다.

- 하지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다.

1) 깨끗한 테스트 코드 유지하기

- 테스트의 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 단위 테스트이다.

- 테스트 코드가 지저분하면 코드를 변경하는 능력이 떨어지며 코드 구조를 개선하는 능력도 떨어진다.

- 테스트 코드가 지저분할수록 실제 코드도 지저분해진다.

- 테스트 코드는 실제 코드만큼 중요하기 때문에 실제 코드처럼 깨끗하게 작성해야 한다.

- 테스트 케이스가 있으면 변경이 쉬워진다.

2) 깨끗한 테스트 코드

- 깨끗한 테스트 코드를 만들려면 가독성이 중요하다.

- 테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다.

3) Build-Operate-Check Pattern

- 테스트 자료를 만든다 -> 테스트 자료를 조작한다. -> 조작 결과가 올바른지 확인한다.

- 테스트 코드는 필요한 자료 유형과 함수만을 사용한다.

4) 도메인에 특화된 테스트 언어

- 테스트 코드는 도메인에 특화된 언어(DSL)로 구현해야 한다.

- 흔히 쓰는 시스템 조작 API를 사용하는 대신 API 위에 함수와 유틸리티를 구현한 후 사용하므로 테스트 코드를 작성하기도 쉽고 가독성도 높아진다.

- 이러한 방식으로 구현한 유틸리티는 테스트 코드에서 사용하는 특수 API가 된다.

- 즉, 테스트를 구현하는 개발자와 다른 개발자를 도와주는 테스트 언어이다.

- 숙련된 개발자라면 자기 코드를 좀 더 간결하고 표현력이 풍부한 코드로 리팩토링해야 마땅하다.