TDD 도입이 왜 중요한지에 대한 개인 회고

테스트 코드가 중요한건 개발자라면 누구나 인지하고 있다.
하지만 생각보다 테스트 코드를 작성하는게 쉽지가 않다.
어디부터 작성을 해야 하는걸까?
뭘 어떻게 작성을 해야 하는걸까?
그러다 개발이 종료된 이후에 테스트 코드를 도입하게 된다.
그러면 의문이 드는게 검증이 되었는데 테스트 코드를 왜 짜는지에 대한 회의감이 들기 시작한다.
결국 테스트코드는 작성하지 않는 꼴이 되버린다. 또 문제가 개발을 2번하는 느낌이 든다.
이상하다. 분명 테스트 코드를 중요하다고 해서 테스트 코드를 짜는데 이게 따로 일을 하는 느낌이 든다.
마치 구현 작업과 테스트 코드 작성 작업이 분리된 느낌이다.
이게 나쁘다는게 아니다. QA테스트 같은 경우 개발이 완료된 이후에 QA가 테스트를 하게 된다.
그러면 결국 2가지일을 따로 하게 될 수 도 있어 이러한 방식이 이상하지는 않는다.
위에서 언급했듯이 개발이 종료된 이후에는 귀찮다고 거의 테스트 코드를 작성하지 않는다. 왜냐하면 검증이 되었기 때문이라 생각한다.
솔직히 API 테스트를 열심히 돌리면 이걸로도 검증이 되기 때문이다.

이러한 문제를 해결하기 위해 안성맞춤인 개발론이 TDD다. TDD가 테스트코드를 먼저 작성하라고 해서 모든 코드보다 먼저 작성하라는 뜻은 전혀 아니다.
템플릿은 먼저 만들어도 된다. 그러니까 단위테스트를 하는데 컨트롤러 보다 먼저 테스트 코드를 작성할 필요가 없다는 뜻이고
테스트 코드에서 서비스가 필요하기 때문에 서비스 클래스정도는 있어도 크게 상관없다.
하지만 핵심은 구현 코드보다 먼저 작성을 하는것이 핵심이다.
이래도 TDD에 부합하게 된다. 왜냐하면 어쨋든 테스트를 먼저 작성했으니까 말이다.
결국 TDD는 전체 프로세스에 대해 TDD를 할 수도 있지만 부분적으로 특정 서비스에 대해 TDD를 적용할 수 있다고 생각한다.
 이렇게 되면 자연스럽게 구현코드보다 테스트 코드를 먼저 작성하게 되고
그거에 맞춰 개발이 진행이 되기 때문에 구현코드와 테스트 코드는 하나의 테스크로 동작하게 되어진다.
그러면 내가 위에 언급했던 따로 개발한다는 느낌은 덜 받게 될거다.

결론은 TDD 도입이 중요한 이유는 대부분 개발자들이 테스트 코드의 중요성은 알지만 구현이후에 테스트 코드를 작성할려고 하니 이미 검증이 되었다고 생각하는 것을 생각의 전환을 통해 자연스럽게 하나의 테스크로 테스트 코드를 작성하기 위한 방법이라 생각한다.