단위 테스트를 작성할 때, 테스트 대상 코드가 의존하는 타입을 목(mock) 처리하는 것은 일반적인 관행입니다. 하지만, 당신이 소유하지 않은 타입(types you don’t own)을 목 처리하는 것은 거의 항상 피해야 합니다.

단위 테스트를 작성할 때, 테스트 대상 코드가 의존하는 타입을 목(mock) 처리하는 것은 일반적인 관행입니다. 하지만, 당신이 소유하지 않은 타입(types you don’t own)을 목 처리하는 것은 거의 항상 피해야 합니다.

만약 당신이 과속 운전을 한다면(원인), 당신은 교통 딱지를 받게 될 것입니다(결과).

일반적으로 상태를 변경하지 않는 메서드가 호출되었는지 검증하는 것은 피해야 합니다.

과도하게 중첩된 코드는 가독성을 해치고 오류를 발생시키기 쉽습니다.

만약 당신이 과속 운전을 한다면(원인), 당신은 교통 딱지를 받게 될 것입니다(결과).

End-to-end(E2E) 테스트는 시스템의 한쪽 끝에서 다른 쪽 끝까지, 그 사이의 모든 것을 블랙박스로 취급하며 전체 시스템을 테스트합니다. E2E 테스트는 시스템 전반에 걸쳐 나타나는 버그를 잡아낼 수 있습니다. 단위 테스트, 통합 테스트와 더불어 E2E 테스트는 균형 잡힌 테스트 식단의 핵심적인 부분이며, 운영 환경과 거의 유사한 상태에서 시스템의 건전성에 대한 확신을 줍니다.

변경 감지 테스트는 부정적인 가치(- value)를 제공합니다. 테스트가 어떤 결함도 잡아내지 못하면서, 추가적인 유지보수 비용이 개발 속도를 늦추기 때문입니다. 이러한 테스트는 다시 작성되거나 삭제되어야 합니다.

Public API 는 수많은 사용자에 의해 호출될 수 있으며, 사용자들은 메서드에 가능한 모든 입력 조합을 전달할 수 있습니다. 여러분은 이 API들이 잘 테스트되었는지 확인하고 싶을 것입니다. 그래야 사용자들이 API를 사용할 때 문제를 겪지 않을 것이기 때문입니다.

테스트 이름에 시나리오와 예상 결과를 모두 넣는 것은 여러 가지 이점을 가집니다.