개발자가 직업과 취미를 가르는 기준은 돈을 받냐 안 받냐 차이라고 생각해요.
비즈니스적으로 코드의 가치를 증명해야하는데 그 중 하나는 품질 보증이라고 느꼈어요.
먼저 테스트 코드를 작성하며 질문을 통해 개발을 진행해야한다는 부분에서 테스트만 잘 구성한다면 최소 품질 보증이 되겠다고 느꼈어요.

이런 점이 특징이에요

최소 품질 보장을 할 수 있다.

리팩토링 과정에서 최소 품질 보장이 어려워 지는 것을 어느정도 막을 수 있어요.
테스트 항목에 white-box 테스트를 중심으로 black-box 테스트를 하면 기본적인 최소 품질 보증이 되었다고 할 수 있어요.
운영 단계에서 로직을 수정하는 것과 개발 단계에서 로직을 수정하는 비용은 100배 이상 차이 난다고 해요.

오버엔지니어링을 방지할 수 있다.

TDD없이 개발을 하다보면 요구사항에 없는 내용도 주관적인 판단으로 미리 만드는 경우가 있어요. 기능이 많으면 좋을 수 있지만 요구사항에 없는 행동은 결국 비용 초과에요.
TDD는 테스트 질문을 통해 요구사항을 정의하기 때문에 추가 행동을 자제하고 비용을 아낄 수 있어요.

이런 점을 주의해야 해요

초기 개발 시간이 증가한다.

테스트를 위한 추가 코드를 작성해야 하기 때문에 물리적으로 시간이 증가해요.
단기적인 일회성 프로젝트에는 적합하지 않을 수 있어요.

초록막대 증후군에 걸릴 수 있다.

작성한 테스트만 믿고 배포하다가 예외가 발생하는 것에 안일할 수 있어요.
테스트는 모든 품질이 아닌 최소 품질만 지킨다는 것을 알고 있어야 해요.

요구사항과 테스트케이스의 우선순위가 역전될 수 있다.

테스트 질문이 주관적이지 않은지 다시 본인에게 물어봐야 해요.
요구사항이 최우선이라는 것을 잊지 않고 객관적으로 작성해야해요.

Classicist와 Mockist 방식을 이해하고 작성.

mock은 특정 함수의 특정 행동을 모방하는 기술이에요.
Mockist는 mock사용을 핵심으로 테스트를 작성해요.
로직 경로를 하나하나 세밀하게 테스트가 가능해서 매우 단단한 품질보증을 지향해요.
대신 의존성이 매우 높아 아키텍처에 수평적인 리팩토링이 일어나면 대량의 테스트를 다시 수정해야 할 수 있어요.
Classicist는 mock의 사용을 최소화하고 실제 환경과 비슷한 시나리오를 지향해요.
테스트와 의존성이 낮아 수평적인 리팩토링에 영향력이 낮아요.
대신 정밀한 예외처리가 상대적으로 약할 수 있어요.
Classicist를 지향하면서 민감한 정보를 다루는 부분에는 mock테스트로 품질을 지키면서 유연한 개발을 해야 해요.

결론

엔지니어는 요구사항 아래에서 비용을 최소화하는 것에 목표를 두어야 해요.
기술을 편향적이지 않고 상황에 맞게 적용하는 것이 중요해요.
TDD도 요구사항을 적은 비용으로 달성하기 위한 수단일 뿐이에요.