TDD 란?
Test-Driven Development의 약자로, 테스트가 코드 작성을 주도하는 개발방식이며, 매우 짧은 개발 사이클의 반복에 의존하는 소프트웨어 개발 프로세스이다.
우선 개발자는 요구되는 새로운 기능에 대한 자동화된 테스트케이스를 작성하고, 해당 테스트를 통과하는 가장 간단한 코드를 작성한다. 일단 테스트를 통과하는 코드를 작성하고, 리팩토링하는 과정을 거치는 것이다.
장점
코드를 작성하기 전에 보다 요구사항에 집중
테스트를 작성하기 전에 개발자는 해당 기능의 요구사항과 명세를 분명히 이해하고 있어야한다. 이는 user-case나 user-story 등으로 이해할 수 있으며, 이는 개발자가 코드를 작성하기 전에 보다 요구사항에 집중할 수 있도록 도와준다. 이는 TDD가 주는 이점 중 하나이다.
기존의 기능이 잘 작동하는지 확인
새로운 기능을 추가하면, 잘 작동하던 기능이 제대로 동작하지 않을 때가 많다. 또 개발자가 미처 인지하지 못하는 경우도 있다. 이러한 경우를 방지하기 위해 테스트 코드를 작성하여, 새로운 기능을 추가할때 기존의 기능들이 잘 작동하는지 확인해 볼 수 있다.
더 빠른 리팩토링
TDD를 해왔다면 방대한 코드량을 안심하고 리팩토링할 수 있다. 리팩토링을 하면서 해당 기능이 오작동을 일으킨다면 테스트가 잡아줄 것이기때문이다. 결과적으로 리팩토링이 더 빨라지고, 코드의 퀄리티도 그만큼 향상하게 된다.
단점
코드의 생산성
요구되는 코드량은 분명히 늘어난다. 코드 퀄리티보다 빠른 생산성이 요구되는 시점에서 TDD는 큰 걸림돌이 될 수 있다.
테스트 코드 작성의 어려움
어떤 부분을 테스트해야할지, 어떻게 테스트해야할지, 어떤 테스트 프레임워크가 적합한지에 대한 학습이 필요하고, 익숙해지는데에도 시간이 걸린다. 개발팀 전원이 이에 익숙해져야하기에 이에 대한 코스트는 무시할 수 없다.
테스트를 작성할 수 없는 상황
다양한 요구사항과 예외 케이스를 맞추다보면, 테스트를 작성하는 것이 불가능하거나 매우 어려울 수 있다. 이때 실제 코드를 변경하여 테스트에 적합한 코드를 만드는 것은 주객전도인 상황이다.
따라서 모든 코드에 대해 테스트를 작성할 수는 없으며, 할 필요도 없다. 테스트코드를 작성한다고 버그가 발생하지 않는 것도 아니다. 또 TDD는 100% coverage와 100% 무결성을 주장하지 않는다.
출처
https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/Development_common_sense#restful-api