이번 인턴 중 코드리뷰를 받으면서 TDD란 단어를 들었다.
너무 생소한 단어였지만 code test와 관련된 이야기를 하던 중이라 unit test session에서 들었던 이야기와 비슷한 이야기겠구나라고 생각하며들었다.
하지만 내 코드에 대한 테스트가 앞으로의 유지·보수의 최저 기준이 될 수있다는 세션 내용을 기억하고도 쉽게 흘려들을 수는 없어 과연 TDD가 무엇인지 알아보는 포스팅을 쓰기로 했다.

1. TDD(Test-driven development)

TDD는 software development process의 줄임말로 테스트 주도 개발이라고 한다. 소프트웨어 개발 방법의 하나로 소프트웨어가 완전히 개발되기 전 테스트 케이스를 사용해 소프트웨어의 요구사항을 실행하고 모든 테스트 케이스에 대해 반복적으로 테스트 케이스를 실행하여 모든 소프트웨어의 개발을 추적하는 소프트웨어의 개발 방식이다.
간단하게 말하면 개발 전, 새 코드를 작성하기 전에 실패 테스트(test code)를 작성하고 개발을 하는 방식이다. 즉, 테스트가 주가 되는 개발방식으로 처음부터 테스트를 염두해 둔 프로그램 개발 방법이다.

• 기존방법
  설계 => 개발 => 테스트

• TDD
  설계 => 테스트 코드 작성 => 개발
  

TDD 순서

1) Add test 테스트 추가
매우 간결한 기능 및 기능 개선 사항을 정의하는 테스트 작성. 테스트 작성을 위해 개발자가 기능 사양 및 요구 사항을 명확하게 이해해야한다.

2) Run all tests and see if the new test fails
모든 테스트 확인 및 새로운 테스트가 실패하는지 확인
테스트 하네스(test harness)가 제대로 작동하는지 확인 하고 새 코드를 요구하지 않고 새로운 테스트를 통과하지 못 하는 것을 보여준다. 새 테스트에 결함이 있고 항상 통과 할 가능정을 배제한다. 새 테스트는 예상되는 이유로 실패해야 한다.

3) Write the code 코드 작성
테스트를 통과하는 코드를 작성한다. 새 코드는 완벽하지 않으면 테스트를 통과하는 것을 목적으로 한다.

4) Run test 테스트 실행
모든 테스트가 통과하면 개발자는 새 코드가 테스트 요구사항을 충족하고 기존 기증을 손상하거나 저하시키지 않는다고 확신 할 수 있다. 그렇지 않을 경우 새 코드가 조정 될 때까지 조정해야한다.

5) Refactor code 코드 리팩토링
테스트를 통과만 한 코드를 리팩토링한다. 중복을 제거해야한다.

6) Repeat 반복
또 다른 새로운 테스트를 시작으로 주기를 반복한다. 단꼐의 크기는 항상 작아야하고 각 테스트 실행 사이에 1 ~ 10번의 편집을 해야한다.

중요
단위는 항상 작게 유지해야한다. 단위가 작을 수록 디버깅하기가 쉽고 읽고 이해하기 더 쉽다.

유닛 테스트의 중요성에 대해서는 많이 보고 들어서 알고 있었지만 방법론?에 대해서 정확한 명칭을 알게 된 것은 TDD가 처음이다. 아쉽게도 아직까지 TDD를 적용해본 적이없고 심지어 테스트 코드 조차 작성해본 적이 없다. 사실 테스트 코드조차 어떻게 작성해야하는지 감도 안 오고 단지 관련 라이브러리가 있다고 하니 찾아볼 생각이다.

아직까지는 유닛테스트가 필수적인 백엔드에 비해 프론트엔드에서 테스트코드를 작성하는 경우는 많지 않다고 하나 어쨌거나 테스트코드를 작성하는 방식은 점점 넓어질 것이니 필히 익혀야 한다고 생각한다.

테스트라는 것이 얼마나 중요한지 모르는 사람이 과연 있을까? 단지 현실적인 문제에 시간적 문제로 하지 못 하는 것뿐이라고 생각한다.

내가 본 글에 테스트 코드를 작성하는 것이 실제 생산성이 더 좋다고 하는데 과연 그냥 적힌 말인지 실제인지는 해봐야 하는 것이지만 장기적으로 봤을 때 이 TDD 방식은 최저 수준의 코드를 보장하는 방식이 될 것이라고 생각한다.

반드시 이 테스트 코드 작성에 대해서 다시 써보면서 익혀야겠다는 다짐을 해본다.