20180504 TDD

개요

단순 코드 리팩토링 뿐만 아니라 프로젝트 구현의 생산성 증대를 위해서는 TDD는 매우 중요한 것 같다. 따라서 이에 대한 지식 부족으로 공부한다. 향후 나의 밑거름이 도움이 되길 바라는 마음.

해당 내용은 켄트 백의 Test-Driven Development : By Example 도서를 참고하였습니다.

일반적인 TDD의 주기는 다음과 같다.

• 테스트를 작성한다. 마음 속에 있는 오퍼레이션이 코드에 어떤 식으로 나타나길 원하는지 생각해보라. 이야기를 써내려가는 것이다. 원하는 인터페이스를 개발하라. 올바른 답을 얻기 위해 필요한 이야기의 모든 요소를 포함시켜라
  

• 실행 가능하게 만든다. 다른 무엇보다도 중요한 것은 빨리 초록 막대를 보는 것이다. 깔끔하고 단순한 해법이 명백히 보인다면 그것을 입력하라. 만약 깔끔하고 단순한 해법이 있지만 구현하는 데 몇 분 정도 걸릴 것 같으면 일단 적어 놓은 뒤에 원래 문제(초록 막대를 보는 것)로 돌아가자

• 올바르게 만든다. 이제 시스템이 작동하므로 직전에 저질렀던 일들을 수습해야 한다. 좁고 올곧은 소프트웨어 정의의 길로 되돌아와서 중복을 제거하고 초록 막대로 되돌리자

우리의 목적은 깔끔한 코드를 얻는 것이다. 작동하는 깔끔한 코드를 얻는 것은 떄로는 최고의 프로그래머들조차 도달하기 힘든 목표이고, (중략) 한번에 깔끔한 코드를 얻을 수 없다면 분할정복(Divide And Conquer)하자. 

"작동하는 깔끔한 코드" 를 얻어야 한다면 전체 문제 중에서 "작동하는" 에 해당하는 부분을 먼저 해결하고 이후에 "깔끔한 코드" 를 해결하도록 하자. 이러한 접근 방식은 "깔끔한 코드" 부분을 해결하고 이후에 "작동하는" 부분을 해결하는 아키텍처 주도 개발과는 정반대이다.

책에서 초록색 막대를 최대한 빨리 보기 위해서 수행한 전략 두 가지

1. 가짜로 구현
   상수를 반환하게 하고, 진짜 코드를 얻을 때까지 단계적으로 상수를 변수로 바꾸어 나간다.
2. 명백한 구현 사용
   실제 구현을 입력

책에서는 아래와 같은 내용들을 배웠다.

• 설계 상의 결함 (Dollar 부작용)을 그 결함으로 인해 실패하는 테스트로 변환했다.
• 스텁구현으로 빠르게 컴파일을 통과하도록 만들었다.
• 올바르다고 생각하는 코드를 입력하여 하나의 테스트를 통과했다.

오퍼레이션

보통 메소드와 비슷한 의미로 쓰이며, 객체가 수행할 수 있는 연산을 의미한다. 엄격하게는 오퍼레이션에 대한 특정한 하나의 구현을 메소드라고 부른다. 언어가 다형성(polymorphism)을 지원하는 경우 한 오퍼레이션은 여러 메소드를 가질 수 있다.

스텁(Stub)

정해진 질문에 대해서 사전에 준비된 답을 의미한다. 예측 가능한 요청에 대해서 미리 만들어 놓은 응답을 작성한 뒤 해당 응답을 반환하는 것이다. 테스트 스텁을 사용함으로써, 의존하는 것에 독립적으로 개발 및 테스트가 가능하며, 촘촘한 테스트를 할 수 있다. 스텁으로 다양한 응답결과(canned answer) 케이스를 만들어 테스트할 수 있다.