코드가 처음 작성될 때 그리고 수정될 때마다 코드가 의도한 대로 작동한다는 것을 스스로 확신할 수 있는 방법이 필요하다. 테스트는 이런 확신을 하기 위한 주된 방법이다.
좋은 단위 테스트는 어떻게 작성할 수 있는가?
다음은 좋은 단위 테스트가 가져야 할 5가지 주요 기능이다.
- 훼손의 정확한 감지: 테스트는 코드가 실제로 훼손된 경우에만 실패해야 한다.
- 세부 구현 사항에 독립적: 세부 구현 사항을 변경하더라도 테스트 코드는 변경하지 않는 것이 이상적이다.
- 잘 설명되는 실패: 테스트 실패의 원인과 문제점을 명확하게 설명해야 한다.
- 이해할 수 있는 테스트 코드: 테스트 코드가 무엇을 테스트하는지와 어떻게 테스트가 수행되는지 이해할 수 있어야 한다.
- 쉽고 빠르게 실행: 단위 테스트가 느려서는 개발 시간이 낭비되지 않도록 해야한다.
훼손의 정확한 감지
플래키: 테스트 대상 코드가 정상임에도 불구하고 때로는 통과하거나 때로는 실패하는 테스트를 말하며, 무작위성, 타이밍 기반 레이스 조건, 외부 시스템에 의존하는 등의 테스트 비결정적 동작에 기인한다.
이렇게 플래키 테스트로 인해 실패의 원인을 찾느라 시간을 낭비할 수 있으므로 코드에서 어떤 부분이 훼손될 때 그리고 오직 훼손된 경우에만 테스트가 실패하도록 하는 것이 중요하다.
퍼블릭 API에 집중하되 중요한 동작은 무시하지 말라
중요한 동작이 퍼블릭 API 외부에 있을 수 있다.
예를 들어 커피 자판기를 테스트한다고 할 때, 고객이 커피를 사고 받기까지의 일련의 동작, 즉 기계와 고객의 상호작용을 테스트할 수 있을 것이다. 하지만 커피 자판기가 가진 퍼블릭 API 이상의 것을 고려해야 할 필요성이 있다. 커피 자판기는 전원이 켜져야 하고 내부에 물과 커피가 있어야 동작하기 때문에 이와 같은 의존성에 대해서도 고려해야 한다.
즉, 테스트는 가능하다면 퍼블릭 API를 사용해서만 테스트하는 것을 목표로 해야하지만 퍼블릭 API 외에 퍼블릭 API의 일부가 아닌 종속성과 상호작용해야 하는 경우가 많다.
- 서버와 상호작용하는 코드
- 데이터베이스에 값을 저장하거나 읽는 코드
테스트 더블
테스트 더블은 의존성을 시뮬레이션하는 기법으로 테스트 단순화, 테스트로부터 외부 세계 보호, 외부로부터 테스트 보호를 위해 사용한다.
테스트 더블은 목(mock), 스텁(stub), 페이크(fake)라는 세 가지 유형의 테스트를 가진다.
테스트 철학으로부터 신중하게 선택하라
테스트 주도 개발(test-driven development, TDD): 실제 코드를 작성하기 전에 최소한의 테스트 케이스를 먼저 작성하는 것을 말한다.행동 주도 개발(Behavior Driven Development, BDD): 사용자의 관점에서 소프트웨어가 보여야 할 행동을 식별하는데 집중하는 방법론을 말한다.수용 테스트 주도 개발(Acceptance Test Driven Develpoment, ATDD): BDD와 비슷하지만 사용자의 관점에서 소프트웨어가 보일 동작을 식별하고 필요에 따라 작동하는지 검증하기 위해 자동화된 수락 테스트를 말한다. TDD와 마찬가지로 실제 코드를 구현하기 전에 테스트를 생성해야 하낟.
