어차피 테스트 코드를 작성한다면 TDD 방법론을 채택하는 게 이득이라고 생각한다. 여러 이점이 있지만 요즘 다른 회사 개발팀 코칭을 하며 자주 체감하는 건 구현이 아닌 요구사항에 집중하여 엣지 케이스를 더 잘 챙기게 해주는 덕에 거짓 음성(운영 코드가 틀렸는데 테스트는 통과하는 것)을 줄여주기 쉽다는 것이다.

테스트 코드를 운영 코드 구현 이후에 작성하면 구현 절차나 분기에 맞춰 테스트 케이스를 만들게 되는 경향 때문에 엣지 케이스를 곧잘 빼먹게 된다. 이러면 리팩토링을 할 때 거짓 음성이 발생하기 쉬워진다. 리팩토링까지 안가더라도 요구사항을 한 번이라도 먼저 고민해보는 일은 엣지 케이스를 더 잘 챙기게 도와준다.

현실에서는 더 복잡한 경우가 많지만 아주아주 심플한 사례를 만들어보자면 숫자 두 개를 비교하는 함수를 만들 때 두 숫자가 같은 경우에 대한 엣지 케이스를 빼먹기 쉽다.