November 17, 2021 2 min to read

9. 단위 테스트

TDD 법칙 세 가지

이런 식으로 테스트 케이스를 짜게 되면 사실상 실제 코드를 전부 테스트하는 테스트 케이스가 나오게 되지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발할 수 있다.

실제 코드가 변경되면 이에 따른 테스트 코드도 함께 수정이 되어야 한다. 하지만 최초에 구현한 테스트 코드를 지저분하게 구현해둔 상태라면 이후 테스트 코드 추가 또는 수정 작업이 어려워질 수 있다.
즉, 테스트 코드를 대충 짤 바에야 안짜는 게 더 나을 수 있다.

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

테스트 코드는 사고와 설계와 주의가 필요하다. 실제 코드 못지 않게 깨끗하게 짜야 한다.

테스트 코드를 깨끗하게 유지하지 않으면 결국 잃어버린다. 그리고 테스트 케이스가 없으면 실제 코드를 유연하게 만드는 버팀목도 사라진다.

코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다. 테스트 케이스가 있다면 실제 코드 수정이 두렵지 않기 때문이다.

가독성은 실제 코드보다 테스트 코드에 더욱 중요할 수도 있다. 가독성을 높이려면 명료성, 단순성, 풍부한 표현력이 필요하다.

테스트 코드는 물론 단순하고 간결하며 표현력이 풍부해야 하지만, 실제 코드 만큼 효율적일 필요는 없다.

Junit으로 테스트 코드를 짤 때는 함수마다 assert 문을 단 하나만 사용하는 것이 테스트 코드 이해하기 더 쉽다.(given-when-then)
하지만 항상 그런 것은 아니다. 상황에 따라 함수 하나에 여러 assert를 넣는 것이 효율적일 때도 있다.

함수 당 assert 문 개수는 최소로 줄이자

함수 하나에 잡다한 개념을 연속으로 테스트하는 것은 피한다.

테스트는 빨라야 한다. 테스트 동작 속도가 느리면 마음대로 테스트 코드 수정도 못하게 되어 코드 품질이 망가질 수 있다.

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

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

테스트는 boolean 타입 값으로 결과를 내야 한다. 통과 여부를 알지 못해 log 파일을 열어야 하는 상황이 발생하면 안된다.

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

테스트 코드는 실제 코드만큼 중요하다. 지속적으로 클린하게 관리해야 한다.