9월 4일에 넷스루 오재훈님께서 TDD 를 주제로 2시간동안 워크샵을 진행하신다고 해서 참석했다. 그동안 TDD를 해봐야지 하고 책도 봤지만 막상 실무에 적용 하려면 막막했었다.

과연 어떤 힌트를 얻을 수 있을까 기대를 품고 갔는데, 다녀오길 잘 했다는 생각이 든다.

가장 막막했던 첫 시작을 어떻게 해야 할까?

시작점 : 요구사항

TDD는 “1 실패 케이스 작성” -> “2 성공하는 케이스 작성” -> “2의 리팩토링” ->” 1의 리팩토링 “-> “1 실패 케이스 작성”의 반복이다.

그러면 “1 실패 케이스”는 무엇인가? 이것이 바로 요구 사항이다. 처음에는 하드 코딩으로 시작해도 좋다. 그러면 리팩토링 거리가 생기겠지. 그럼 리팩토링 하면 된다. 그리고 계속 반복 개선해나가면 되고.

테스트 드리븐

처음에는 아마 테스트 코드만 작성 했을 수도 있다. 그러나 우리가 원하는건 제품 코드이다. 현재 테스트 코드에 있지만 제품 코드에 사용되어야 할 부분을 분리하는 리팩토링 작업을 한다. 제품 코드가 테스트 코드에서 나왔기 때문에 테스트 드리븐인 것이다.

의존성 낮추기

제품도 테스트도 계속 발전하고 크기가 커져 복잡도가 높아진다. 그렇다고 해서 성공 테스트 케이스가 실패 테스트 케이스로 변하면 곤란한 상황에 처했다는 신호이다.

이것을 위해 제품코드와 테스트 코드의 연결 고리는 인터페이스여야 하며, 필요하다면 제품코드와 테스트 코드 사이의 헬퍼 클래스를 작성 해야 할 수도 있다.

코드 정제하기

처음 솔루션을 개발 할 때는 하드 코딩 처럼 특수한 케이스에 맞는 것을 작성하고 그것을 케이스에 맞춰 점차 일반화 시킨다. 하드 코딩에서 일반화된 코드로 가는 방법은 중복된 코드를 제거하는 것이다.

TDD의 끝

더이상 실패 케이스를 작성 할 수 없으면 모두 끝이 나게 된다.

나쁜 테스트 코드

if, for 문이 많이 들어간 테스트 코드는 안좋을 확률이 높다.