[CleanCode] 9. 단위 테스트

로버트 C. 마틴의 클린코드 9장을 읽고 정리한 내용이다.

 

TDD 법칙 세 가지

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

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

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

 

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

테스트 코드는 실제 코드 못지 않게 중요하다.

그 이유는, 테스트 코드가 지저분할수록 변경하기 어려워지며, 실제코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리기 때문이다.

결국, 실패하는 테스트 케이스를 점점 더 통과시키기 어려워져, 테스트 코드는 계속해서 늘어나는 부담이 되버린다.

때문에, 테스트 코드는 사고와 설계와 주의가 필요하다.

∴ 실제코드 못지 않게 깨끗하게 짜야 함 (가독성 중요 / 명료성, 단순성, 풍부한 표현력 필요)

 

테스트는 유연성, 유지보수성, 재사용을 제공

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

테스트 케이스가 없다면, 모든 변경이 잠정적인 버그다. 

 

테스트 당 assert 하나씩                   

Junit 으로 테스트 코드를 짤 때, 함수마다 assert 문을 단 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다.

굳이 assert문이 하나가 아니더라도, assert 문 개수는 최대한 줄여야 좋다. 

 

F.I.R.S.T

꺠끗한 테스트는 다음 다섯 가지 규칙을 따른다.

- Fast (빠르게)

테스트는 빨라야 한다. 

- Independence (독립적으로)

각 테스트는 서로 의존하면 안된다. 한 테스트가 다음 테스트가 실행될 환경을 준비해서는 안된다.

- Repeatable(반복가능하게)

테스트는 어떤 환경에서도 반복 가능해야 한다.

- Self-Validating(자가 검증하는)

테스트는 부울(bool) 값으로 결과를 내야 한다. (성공 / 실패)

통과 여부를 알려고 로그 파일을 읽게 만들어서는 안된다.

- Timely(적시에)

테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.

 

 

테스트 코드는 실제코드의 유연성, 유지보수성, 재사용성을 보존하고 강화하기 떄문에 지속적으로 깨끗하게 관리해야할 필요가 있겠다. 테스트 API를 구현해 도메인 특화 언어(DSL;Domain Specific Language)를 만들자.

 

 

확실히 15쪽의 분량으로는 부족한 것 같아 책을 한권 구입했다.

자바와 Junit을 활용한 실용주의 단위테스트를 읽고 좀 더 자세하게 테스트에 대해 알아봐야겠다.