9. 단위테스트

TDD (Test Driven Development)

1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위테스트를 작성한다.
3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

→ 개발 - 테스트 30초 주기로 진행하면 TC와 실제 코드가 함께 나온다!

→ TC의 증가는 관리 문제를 유발하기도 한다.

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

• 지저분한 TC는 변경이 어렵다. (실코드를 변경하면 TC도 변경이 필요하게 됨) : TC에 대한 유지보수 비용이 증가한다.
  • 하지만 TC를 포기하게 되면 수정한 코드가 제대로 도는지 확인할 방법이 없기 때문에 코드 변경에 있어 주저하게 되고 코드가 망가질 수 있음.
  • 그러므로 TC는 사고, 설계, 주의가 필요하다. TC도 실제 코드만큼 깨끗하게 짜야한다.
• 테스트는 실제 코드의 유연성, 유지보수성, 재사용성을 제공한다.

깨끗한 테스트 코드

• 가독성이 제일 중요!!! - 명료성, 단순성, 풍부한 표현력이 필요함
  • 잡다한 코드는 최대한 없애고(함수나 유틸로 분리) 테스트의 목적이 보이도록 구현
  • 이중 표준: 실제 환경에서는 절대 이렇게 짜면 안되지만 가독성이 중요한 TC에서는 사용하는 것 (ex. 164p. 참고)

테스트 당 개념 하나

• 하나의 TC에는 테스트할 하나의 개념만 넣는다.

깨끗한 테스트를 만드는 5가지 규칙 (F.I.R.S.T)

• Fast: 테스트는 빨리 돌아야 한다.
• Independent: 각 테스트는 서로 의존하면 안됨.
• Repeatable: 어떤 환경에서도 반복 가능해야 한다.
• Self-Validating: 테스트는 bool 값으로 결과를 내야 한다.
• Timely: 테스트는 적시에 작성 되어야 한다. (단위 테스트는 실제 코드 구현 직전에 짠다.)

---

일할 때 TC를 짜는 게 정말 일이었다. 기존 코드들도 전혀 테스트 되고 있지 않은 상황에서 새로운 스펙 개발을 위해 코드를 구현하다보니 언제나 테스트 코드를 짜는 게 벅찬 기분이었다. 그렇지만 새로 추가하는 코드부터 차근차근 테스트를 넣고, 에러가 발생한 케이스에 대해서도 추가로 TC를 추가하다보니 책에서 말하는대로 코드를 고쳐서 문제가 될 것 같다는 불안감을 조금이라도 줄일 수 있었다. 비록 TDD로 테스트 코드를 추가 한 건 아니었지만, 그래도 테스트 코드를 추가했다는 것만으로도 의미가 있었다! 기회가 된다면 TDD로 개발해보는 것도 너무 신기하고 좋은 경험이 될 것 같다.