제품의 요구사항은 자주 바뀔 수 있지만, 그 근본적인 아이디어는 보통 천천히 변합니다. 이는 흥미로운 통찰로 이어집니다. 만약 우리가 제품의 근본적인 아이디어와 일치하는 코드를 작성한다면, 그 코드는 미래의 제품 변경에도 살아남을 가능성이 더 높습니다.

테스트 피라미드는 테스트 스위트의 발전을 안내하는 정석적인 경험 법칙(heuristic)입니다. 이는 단순한 메시지를 전달합니다. 통합 테스트보다 더 많은 단위 테스트를 선호하고, 엔드 투 엔드(end-to-end) 테스트보다 더 많은 통합 테스트를 선호하라는 것입니다.

함수가 if 문에서 일찍 종료(return)되는 경우, else 절을 사용하는 것과 사용하지 않는 것은 동작상으로는 동일합니다. 하지만 else 절과 가드 절(guard clause, else 가 없는 형태)을 적절히 사용하면 코드를 읽는 사람에게 의도를 더 명확하게 전달할 수 있습니다.

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

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

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

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

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

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

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

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

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

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

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

프로그래밍 언어는 우리에게 많은 표현력을 제공합니다. 연산자와 조건문 같은 개념들은 광범위한 입력을 처리하는 프로그램을 작성할 수 있게 해주는 중요한 도구입니다. 하지만 이러한 유연성은 복잡성 증가라는 대가를 치르게 하여, 우리 프로그램을 이해하기 어렵게 만듭니다.

테스트는 목적을 위한 수단입니다: 프로젝트의 주요 위험을 줄이고, 가장 큰 효과를 얻기 위함입니다. 이 효과는 항상 표준 관행에 따라 작성하는 테스트에서 나오지 않을 수 있으며, 심지어 테스트에서 전혀 나오지 않을 수도 있습니다.

개별 단위 테스트를 작성하든 제품의 전체 테스트 프로세스를 설계하든, 테스트가 코드의 버그를 얼마나 효과적으로 감지하고 보고하는지 다시 한번 생각해보는 것이 중요합니다. 효과적이려면 모든 테스트가 극대화하려고 노력해야 하는 세 가지 중요한 품질이 있습니다.

메서드를 작성한 후 메서드가 수행하는 모든 작업을 확인하는 테스트를 하나만 작성하기 쉽습니다. 그러나 테스트와 public 메서드가 1:1 관계를 가져야 한다고 생각하는 것은 해로울 수 있습니다. 우리가 정말로 테스트하고 싶은 것은 동작이며, 단일 메서드가 여러 동작을 나타낼 수 있고, 단일 동작이 때로는 여러 메서드에 걸쳐 있을 수도 있습니다.

단위 테스트는 코드의 정확성을 확인하는 중요한 도구입니다. 그러나 좋은 테스트를 작성하는 것은 단순히 정확성을 확인하는 것 이상입니다. 좋은 단위 테스트는 읽기 쉽고 유지 보수 가능하도록 여러 다른 속성을 보여야 합니다.

단위 테스트가 테스트 중인 코드가 제대로 작동하는지 확인하는 방법은 일반적으로 두 가지가 있습니다: 상태 테스트 또는 상호작용 테스트. 이들의 차이점은 무엇일까요?