TDD (Test-Driven-Development)란?
Test-Driven-Development의 약자로 테스트주도개발이라는 뜻이다.
테스트 주도 개발이란 코드를 작성 할 때 테스트코드를 먼저 작성 후 개발을 하는 프로세스를 일컫는다. 코드작성을 할 때 테스트코드도 같이 작성하여 이 테스트 코드가 제대로 작동하는지 테스트 후 오류가 발생하면 수정 , 개발 , 수정, 개발 하는 방식으로 개발의 속도가 다소 느려진다고 생각 할 수 있다. 또한 실제로 개발 시간또한 일반적인 개발 방식에 비해 20 ~ 30%가량 늘어난다고 한다. 하지만 TDD 방식의 개발방식은 많은 장점이 존재한다.
개발을 하다 보면 분명히 모두 잘 작동되는 걸 확인 하고 새로운 기능을 추가하였는데 나머지 잘되던 부분까지 안되는 경험이 있을 것이다. 기존의 개발 했던 코드가 얼마 되지 않으면 처음부터 어디서부터 오류가나는지 체크해볼 수 있겠지만 그 양이 많아지게되면 어디서부터 오류가 발생하는지 일일히 찾아보아야 하기 때문에 디버깅하는 시간이 많이 소요 될것이며, 코드를 추가 할때마다 앞에부분도 잘 작동하는지 일일히 테스트해보는건 여간 귀찮은 일이 아닐 수 없다. 하지만 TDD방식의 개발에서는 유닛테스트 후 코드를 작성 후 통합 테스트과정으로 진행 하기 때문에 어느부분에서 오류가 발생하는지 보다 손쉽게 찾을 수 있고, 이로인해 오류가 발생 했을 시 오류를 찾아내는 디버깅 시간을 단축 할 수 있다. 또한 이렇게 작성한 코드는 종속성과 의존성이 낮출 수 있는 방법중 하나이다.
수업시간에는 Nest.JS에서 기본적인 테스트 프레임워크로 지원하는 Jest로 실습 해 보았다.
Nest로 된 새로운 프로젝트를 생성하게 되면 테스트코드에 관한 부분까지 모두 자동으로 생성되고 Jest안에는 다양한 라이브러리들이 모여있는 형태여서 테스트코드를 작성 할 시 다른 라이브러리를 추가해주지 않아도 되는 편리함이 있었다. ex) MOCK
구글링을 해가면서 TDD에 대해 공부하는 중 눈에 띄는 추천검색어가 보였는데 바로 Is TDD Dead 였다. TDD는 죽었다 인데 테스트코드를 작성하는 것이 중요하고 여러모로 유용하다고 생각 했는데 이게 뭐지? 라는 생각이 들어 해당 내용을 검색해 찾아보았다. 2014년에 Rails를 만든 DHH의 말에서 시작된 TDD에 대한 토론으로 보였다. 어떤내용인지에 대해 한글로 번역된 부분을 읽어보고 했지만 아직은 내가 이게 무슨토론이지? 에 대한 생각이 더 크게 들었다. 우리가 흔히 아는 개발자들의 토론하는 문화에 대해 간접적으로 체험 할 수 있었고, 자신들의 의견을 토론하고 공유한다는것이 멋있다고 생각했다. 특히, 전문적인 내용이기 때문에 더 그렇게 느끼는 것일 수 도 있을것 같다. 단순히 테스트코드를 작성하면 귀찮지만 좋겠지 라고 생각했던 나에대해 반성하게 되었다. 생각보다 TTD에 대해 회의적인 부분이 많이 있었다. 그냥 TDD에 대해 회의적인 부분도 꽤 있다. 라는 것을 알 수 있었고 나중에 한번 이 토론에대해 정독해 볼 계획이다.
