061. (Getting Started with Test-Driven Development) 11. TDD 마무리

11. TDD 마무리

11.1. 테스트 우선과 스트레스

일정에 시달려 빨리 구현해야한다는 압박은 코드를 충분히 테스트하지 않고 다음 기능을 구현하게 만든다.

코드를 충분히 테스트하지 않으면 버그가 포함될 가능성이 커지고, 구현한 코드를 테스트 하지 못했다는 사실은 또 하나의 스트레스로 다가온다.

TDD를 적용하는 이런 상황을 바꿀 수 있다.

테스트를 먼저 작성하면 적어도 해당 테스트를 통과한 만큼은 코드를 올바르게 구현했다는 사실을 알 수 있으며, 테스트의 증가로 코드의 신뢰도도 함께 증가한다.

추가한 테스트 코드는 회귀 테스트로 사용할 수 있고, 코드의 수정 전후에 실행하면 다른 기능에 문제가 있는지 바로 확인할 수도 있따.

이때 테스트 코드는 일종의 안정망 역할을 수행하여 버그가 발생할 가능성을 줄여준다.

버그 수정도 더 용이해진다.

버그가 발생하는 상황에 대한 테스트 코드를 추가하고 이를 통과시키면 된다.

새로운 버그가 발생하면 다른 테스트를 실행하는 과정에서 발견되기때문에 불안감도 줄어든다.

11.2. TDD 전파하기

TDD가 익숙해지면 아래와 같은 효과를 누릴 수 있다.

  • 결함 감소
  • 스트레스 감소
  • 빠른 피드백

이를 체감하고 동료들에게 전파하려고 하는 경우, 무턱대로 권유하면 안된다.

TDD를 경험하지 않은 사람의 입장에서 TDD는 완전히 다른 방식이다.

그동안 무시해왔던 테스트 코드를 작성하는 것 자체가 개발 시간을 늘린다고 생각할 수 있기때문이다.

TDD를 전파하기 가장 좋은 방법은 본인이 먼저 TDD에 익숙해진 뒤, 더 적은 결함, 더 적은 스트레스, 더 빠른 개발이라는 가시적인 효과를 동료들에게 보여주어야 한다.

11.2.1. 짝 코딩을 통한 전파

TDD를 도입하기 힘든 주된 이유는 TDD를 할 줄 모르기 때문이다.

개발자에게 TDD를 전파하는 가장 좋은 바업ㅂ은 . 짝코딩을 하는. ㅓ싱다.

짝 코딩은 아래와 같은 형태로 진행할 수 있다.

  1. 테스트 코드를 만들고 실행하는 방법을 보여준다.
  2. 대역을 생성하고 사용하는 방법을 보여준다.
  3. 무엇보다 실제 업무에서 다루는 코드로 TDD를 경험하게 한다.

TDD에 조금씩 익숙해지면 테스트 코드만 만들어주고, 테스트 코드를 통과시키게끔 가이드한다.

이후엔 테스트 코드를 동료가 직접 만들게하되, 옆에서 보조를 해준다.

남이 작성한 테스트 코드를 보기만하는 것과 테스트 코드를 실제로 실행하고 그 결과를 체험하는 것은 다르다.

짝 코딩은 직접 테스트 코드를 경험하게 함으로써 테스트 코드 작성에 대한 거부감을 줄이고 테스트 코드가 주는 이점을 느낄 수 있게 해준다.

11.2.2. 레거시 코드에 대한 테스트 추가

레서기 코드처럼 TDD를 하기 힘든 코드는 테스트 코드라도 만들어보자.

테스트 코드를 만들기 힘들다면 일부 코드를 리팩토링해서 테스트 코드를 만들 수 있는 구조로 변경하는 것이 좋다.

물론 테스트 코드 없이 진행하는 리팩토링은 위험하지만, 테스트 코드를 영원히 만들지 않는 것보다는 나을 수 있다.

레거시 코드에 대한 리팩토링 및 테스트 코드 방법론은 아래 포스팅을 참고하자.

11.3. TDD와 개발 시간

개발 시간은 크게 3가지로 나눌 수 있다.

  1. 코드 작성 시간
  2. 테스트 시간
  3. 디버깅 시간

특정 기능을 구현하기 위해 코드를 작성하고 나면, 해당 기능을 잘 구현했는지 테스트를 하고 문제가 발견되면 디버깅을 수행한다.

위 과정은 개발을 완료할 때까지 반복되므로, 개발 시간은 테스트 전까지의 코드 작성 시간과 테스트 시간, 디버깅 시간을 모두 포함한다.

전체 개발 시간을 줄이려면 코드 작성은 물론 테스트와 디버깅 시간도 둘여야 한다.

테스트 시간을 줄이려면 테스트를 자동화해야하고, 테스트를 자동화한다는 것은 테스트 코드를 작성해야함을 의미한다.

즉, 테스트 코드를 작성하는 것이 테스트 시간을 줄이는 것이다.