제대로 된 테스트 케이스를 작성해보자!

TDD 법칙 세 가지

첫째 법칙

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

둘째 법칙

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

셋째 법칙

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

---

이렇게 일하면 매일 수십 개에 달하는 테스트 케이스가 나온다. 이 방대한 테스트 코드들을 깨끗이 관리해보자.

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

• 유지보수를 위해선 테스트 코드도 실제 코드 못지 않게 깨끗하게 짜야한다.

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

• 테스트 케이스가 있으면 변경 이 두렵지 않다.
• 자동화된 단위 테스트 슈트는 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠다.

깨끗한 테스트 코드

• 깨끗한 테스트 코드를 만들기 위해선 실제 코드만큼이나 가독성 이 정말 중요하다.

BUILD-OPERATE-CHECK 패턴

• 테스트 구조에 적합한 패턴이다. 각 테스트는 명확히 세 부분으로 나눠진다.
• 첫 부분은 테스트 자료를 만든다.
• 두 번째 부분은 테스트 자료를 조작한다.
• 세 번째 부분은 조작한 결과가 올바른지 확인한다.

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

• 테스트를 구현하는 당사자와 나중에 테스트를 읽어볼 독자를 도와주는 테스트 언어다.
• API 위에다 함수와 유틸리티를 구현한 후 그 함수와 유틸리티를 사용하므로 테스트 코드를 짜기도 읽기도 쉬워진다.

이중 표준

• 실제 코드만큼 간결하고, 표현력이 풍부해야 하지만, 실제 코드만큼 효율적인 필요는 없다.
• 테스트 코드는 자원이 제한적이며 실제 코드와는 요구사항이 다르다. 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다.

테스트 당 assert 하나

• JUnit으로 테스트 코드를 짤 때는 함수마다 assert 문을 단 하나만 사용하라 라는 말이 있다.
• assert 문이 단 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽다는 장점이 있다.
• 하지만 테스트를 분리하면 중복되는 코드가 많아진다. 이것저것 잘 따져보고 assert문을 최대한 줄이는 쪽으로 해보자.

given-when-then 관례

• 함수 이름에 이 관례를 적용함으로써 테스트 코드를 읽기 쉬워진다.
• BUILD-OPERATE-CHECK 패턴을 이 이름으로 짜라는 것으로 이해해도,,, 될까,,?

테스트당 개념 하나

• assert 하나보다는 "테스트 함수마다 한 개념만 테스트하라"는 규칙이 낫겠다.

F.I.R.S.T

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

Fast

• 테스트는 자주 돌려야 하므로 빨라야 한다.

Independent

• 각 테스트는 서로 의존하면 안되고 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야 한다.
• 테스트가 서로 의존하게 되면 원인을 진단하기 어려워진다.

Repeatable

• 테스트는 어떤 환경에서든 반복 가능해야 한다. 테스트가 실패한 이유를 둘러댈 변명이 생기면 안된다.

Self-Validating

• 테스트는 bool값, 즉 성공 아니면 실패로 결과를 내야 한다.

Timely

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

결론

테스트 코드는 실제 코드만큼이나 프로젝트 건강에 중요하다.

테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화해주기 때문에, 지속적으로 깨끗하게 관리하자!

Reference

클린 코드: 애자일 소프트웨어 장인 정신 - 로버트 마틴 지음