테스트 주도 개발 주기의 유지

테스트 주도 개발로 배우는 객체 지향 설계와 실천

5장. 테스트 주도 개발 주기의 유지

 

5.1. 각 기능을 인수 테스트로 시작하라

실패하는 인수 테스트를 작성하는 것으로 신기능을 작업하는데 착수한다. 인수테스트는 우리가 작성하려는 기능을 아직 시스템에서 갖추지 못했다는 사실을 보여주고 그 기능이 완성되기까지 진행 상황을 반영한다.

• 인수 테스트 : 응용 도메인에서 나온 용어만 이용한다. (기반 기술. db 등 용어가 아닌)

=> 자동으로 확인 가능한 형태로 요구 사항을 정확하게 표현하면 분명하게 드러나지 않는 가정을 밝히는데 도움이 된다.

=> 실패하는 테스트 덕에 요구사항을 충족하는 데 필요한 만큼의 기능만 구현하는 데 집중할 수 있어 기능을 완성할 가능성이 높아진다.

=> 사용자 관점에서 시스템을 바라보게 되어 구현자 관점에서 기능을 짐작하지 않고 사용자가 필요로 하는 것을 이해하게 된다.

• 단위 테스트 : 객체나 작은 객체 집합을 격리된 상태에서 시험한다.

인수 테스트는 단위 테스트를 거친 객체를 대상으로 통합 테스트를 수행하고, 프로젝트를 진행시킨다.

 

5.2. 회귀를 포착하는 테스트와 진행 상황을 측정하는 테스트를 분리하라

인수테스트 통과 주기 : 중첩 피드백 고리를 구동하는 엔진에 해당 

• 단위테스트, 통합테스트 : 개발 팀을 보조하고 빠르게 실행되어야 한다. 항상 통과해야 한다.
• 완성된 기능에 대한 인수 테스트 : 실행하는데 시간이 오래 걸려도 회귀를 포착하고 늘 통과해야 한다.

 

5.3. 테스트를 가장 간단한 성공 케이스로 시작하라

동작 가능한 가장 간단한 것을 테스트

• 간단한 != 지나치게 단순화한 

=> “피드백을 받을 수 있는” 가장 간단한 것을 테스트해라

• 가장 간단한 성공 케이스로 테스트를 시작

 

5.4. 읽고 싶어 할 테스트를 작성하라

테스트를 시스템이나 객체에서 수행할 행위로 가능한 “명확”하게 표현

테스트가 잘 읽히면 그 다음으로 지원하는 기반 구조를 만든다.

테스트가 어떻게 해야 할지 기술하는 명확한 오류 메시지를 보이면서 예상대로 실패하면 보조적인 역할을 하는 코드를 충분히 구현했다는 사실을 알게 된다. 그러면 해당 테스트를 통과시키는 코드를 작성하기 시작하면 된다.

 

5.5. 테스트가 실패하는 것을 지켜보라

• TDD 주기의 일부로 진단 절차 개선하기

=> 실패 시, 진단 정보를 확인

=> 오류 메시지가 코드와 관련된 문제로 이끌 때까지 테스트 코드를 조정하고 테스트를 재실행

=> 보조 코드를 확장하거나 수정해서 오류 메시지를 늘 명확하고 의미 있게 만든다.

• 오류 메시지를 검사해야 하는 이유

=> 유용한 진단 정보를 생성하는 고생을 감내하면 테스트, 코드에서 해야할 일이 무엇인지 분명하게 하는데 도움이 된다.

 

5.6. 입력에서 출력 순서로 개발하라

외부 이벤트를 받는 객체에서 중간 계층을 거쳐 중심 도메인 모델로 나아간 다음, 외부에서 확인 가능한 응답을 생성하는, 다른 경계에 위치한 객체에까지 => 시스템을 처음부터 끝까지 만들어 나간다.

*** 새 도메인 모델 객체에 단위 테스트를 수행한 후 애플리케이션의 나머지 부분에 해당 객체를 끼워 넣는 식으로 시작하는 것이 쉬워 보일 지라도 나중에 통합 문제로 어려움을 겪을 수 있다. => 불필요하거나 올바르지 않은 기능을 구현했을 수 있음. 도메인 모델을 먼저 작업할 때는 올바른 피드백을 받을 수 없기 떄문

 

5.7. 메서드가 아닌 행위를 단위 테스트하라

보통 메서드 테스트를 먼저 생각함

=> 메서드 테스트는 “목적”이 무엇인지 알려주지 않는다.

• 제공해야 하는 기능에 집중

*** 메서드 테스트로는 각 객체의 동작 방식, 즉 객체의 책임이 무엇이고, 객체의 여러 메서드가 함께 어떻게 동작하는지 이해하기 어렵다.

 

5.8. 테스트에 귀를 기울여라

테스트하기 어려운 코드 영역

=> 설계 개선이 필요 !

지금 당장 코드를 테스트하기 어렵게 만드는 구조 때문에 나중에도 코드를 변경하기 어려워질 것.

테스트를 작성하는 과정 => 잠재적인 유지 보수 문제를 조기에 알려주는 경고 표시

*** 예상치 못한 변화를 예상하라 : 설계에 취약함이 보일 때 리팩토링을 통해 시스템 품질을 유지한다면 어떠한 변화가 일어나도 거기에 대응할 수 있을 것.

 

5.9. 주기의 미세 조정

• 너무 큰 단위로 테스트 수행 => 코드의 모든 가능한 경로를 시도하는 “조합 폭발” 현상 발생 
• 너무 작은 단위로 테스트 수행 => (예를 들면, 클래스 수준으로만) 테스트는 쉽지만 함께 동작하지 않는 객체에 대한 문제는 놓치게 될 것

• TDD를 진행하며 취약한 부분을 찾아보고, 테스트 전략을 조정한다.
• 로직에서 성가신 부분은 단위 테스트(아니면 단순화)가 더 필요할 수 있다.
• 처리하지 않은 예외에는 통합 수준의 테스트가 더 필요할 수 있다.
• 예상치 못한 시스템 실패에는 조사가 더 필요하거나, 테스트를 더 철저하게 해야할 수 있다.