📺 테스트 코드가 필요한 순간

TDD(테스트 주도 개발)에 대한 막연한 환상을 가진 저 같은 사람에게 도움이 되는 영상입니다. 내용을 잘 요약해둔 댓글이 있어 함께 가져왔습니다. - 소프트웨어 개발, 테스팅 또한 경제적인 활동이다. 자원(시간, 인력)을 적게 투입하여 최대한의 효용을 뽑아내어야 한다. 코드에 따라 유닛 테스트는 필요할 때도 있고 필요하지 않을 때도 있다. 유닛 테스트가 필요한 경우는 다음과 같다. 1) 알고리즘이 매우 복잡하지만 수학적으로 잘 정의된 경우, 구현 상의 명백한 버그를 없애기 위해 2) 제품이 실제로 사용되고 발전하면서 자꾸 변하거나 가정이 틀리는 부분의 버그를 없애기 위해 1에서는 TDD가 어느 정도 유용할 수 있으나 2에서는 쓸모가 없다. 코드의 어떤 부분이 변경될지 예측하는 것은 어렵기 때문이다. 1은 애초에 안 변하고, TDD 방식으로 모든 코드에 대해 테스트를 짤 경우, 특히 2에서 코드를 변경해야하는데 테스트가 발목을 잡는다. 그러므로 (포프는) 제품 코드 전에 테스트 코드를 짜자는 TDD 방식을 쓰지 않는다. 일단 코드를 그냥 짜고, 실제로 버그가 일어나고 가정이 틀리는 시점에서 그에 대한 테스트 코드를 작성한다.