한 문단에 한 주제
- 하나의 메서드에대한 하나의 테스트에는 한 가지 주제가 들어가야한다.
- 한개 이상의 경우를 검증하는 테스트를 작성하지말자.
- 논리구조가 들어간 테스트를 지양하자. (ex. if문, 반복문)
- 무엇을 검증하는지 여러가지 논리구조들이 복잡하게 만들 수 있다.
- 한개 이상의 경우를 검증하는 테스트를 작성하지말자.
완벽하게 제어하기
- 테스트시에 랜덤값, 외부 시스템에 연동하는 경우들에 대한 조건에대해 완벽하게 제어할 수 있어야한다.
- 랜덤값, 시간 등… 매개 변수로 예측하거나 검증시 어려운점이 포함 될 경우 매개변수값으로 받거나 랜덤값을 지정해 진행하는 테스트를 내가 완전하게 제어할 수 있어야한다
- 외부 시스템에 연동해 의존하는 경우 Mocking을 통한 Stubbing으로 외부 시스템를 테스트내에서 완전하게 제어할 수 있어야한다.
테스트 환경의 독립성을 보장하자.
- 테스트 주제에 맞지않는 부분에서 테스트 실패가 발생할 경우 테스트 실패 원인파악에 어려움이 발생.
- A() API 테스트를 위해 B() 라는 API가 의존되어 테스트 진행시 테스트 진행중 B()에 문제가 발생해 테스트중 테스트가 실패로 뜬다면 ,
- 최종적으로 우리는 A() API의 검증결과를 확인해야하지만 B()라는 API의 문제로인해 A()의 검증 결과를 확인하지 못하고 원인 파악에 어려움을 겪게 된다.
- 최대한 테스트내에 다른 API 사용을 지양하자.
- 테스트에서는 팩토리 메서드를 지양하자.
- 순수한 생성자, 빌더를 통해 given을 완성하자.
테스트 간 독립성을 보장하자
- 하나의 공유 자원을 이용해 테스트를 진행할 경우 테스트 순서에 따라 테스트가 실패되거나 성공할 수 있다.
- 테스트는 순서, 진행 시간에 영향을 받지않아야한다.
- 특별한 경우가 아니라면 공유 자원 사용을 지양하자.
Private Method 를 테스트하고 싶을 때
Private Method
- 프라이빗 메서드를 테스트할 필요는 없다.
- 퍼블릭 메서드를 테스트하며 이미 검증이 되기 때문
- 만약 프라이빗 메서드의 테스트가 반드시 필요한 상황이라면 그 프라이빗 메서드가 해당 객체의 너무 많은 역할을 주고 있을 경우가 크다.
- 그렇기에 프라이빗 메서드를 해당 객체에서 분리해 새로운 객체로 할당한 뒤 퍼블릭 메서드로 테스트를 진행하자.