회사의 채용공고를 보다보면 우대사항에 "TDD 를 이용한 개발을 해본 자" 라고 적힌 공고가 보인다.
TDD 에 알고 있는 사전 지식은 Test Driven Development 로
실제 코드(운영에 사용될 코드)를 짜기전에 테스트코드를 작성하는 방법으로만 알고 있었다.
이에 따른 장점으로는 기존에 Postman 이나 Swagger Ui 로 직접 요청을 보내면서 했다면, TDD 를 이용한다면 이런 시간을 단축시킬 수 있을 것 같았다.
내가 알고있는정도는 이정도이며 더 자세히 알아보겠다.
테스트를 먼저 만들고 테스트를 통과하기 위한 것을 짜는 것
즉, 만드는 과정에서 우선 테스트를 작성하고 그걸 통과하는 코드를 만들고를 반복하면서 제대로 동작하는지에 대한 피드백을 적극적으로 받는 것이다.
- 아래는 블로그에서 찾아본 좋은 예시이다.
예를 들어, 생년월일(input)을 입력받으면 현재 나이(output)를 출력하는 프로그램
1. 처음에는 간단한 것으로 목표를 정한다. (태어난 해와 올해의 연도를 입력)
2015, 2018 -> (만)3살 우선 이것을 만들겠다는 생각을 한다.
2. 만들기도 전에 만든 후에 무엇을 테스트할지를 설계한다.
2015, 2018를 입력하면 2가 나오는 테스트 프로그램(장차 만들 프로그램을 테스트할 코드)를 만든다.
3. 그 다음에 그 테스트를 통과할 프로그램(1.을 목표로 작성한 코드)를 만든다.
올해의 연도 - 태어난 해
2018 - 2015
4. 테스트 프로그램으로 이 프로그램(3.에 해당하는 코드)을 실행한다.
5. 통과했으면 새로운 테스트를 추가한다.
이번에는 생월을 추가했을 때 계산하는 프로그램
위와 같은 작업을 계속 왔다갔다 수행한다.
- TDD를 하면 개발 시간이 늘어난다.
개발 시간이 TDD를 하지 않을 때에 비해 대략 10~30%가 늘어난다. - TDD를 하면 결함이 줄어든다.
결함이 1/2~1/10 까지 줄어든다.
SW를 개발하면서 예상하지 못했던 시간을 많이 소요하는 것은 대부분이 버그 때문이다.
TDD를 하면 이런 버그를 줄일 수 있다. - TDD를 하면 코드 복잡도가 떨어진다.
깨끗한 코드가 나온다.
유지보수 비용이 낮아진다.
정리를 하자면 TDD를 하면 개발시간이 늘어나지만, 코드의 안정도가 높아지며 유지보수 비용이 줄어든다고 볼 수 있다.
하지만 모든 기업이 TDD를 선호하는 것은 아니다.
그 이유는 단기적인 성과에 집중할 수 밖에 없는 구조가 있을수도 있고, 급한불을 끄는 상황이 많기 때문이다.
또한 TDD가 어렵기 때문이다. 지금 당장의 나같은 경우에도 코드를 짜고난 후에 테스트코드를 짜는 방식으로 했는데 대부분의 사람들은 이런개발방식을 많이 경험했을 것이다.
하지만 이런 특정한 부분에만 국한되는 개발자보다는 조만간 TDD를 연습하여 한층더 다재다능한 개발자가 되야겠다.