1. 12장 테스트 조직하기 아키텍트를 꿈꾸는 사람들 오전스터디 2010. 8. 7. 전효성

2. Goal 찾기 쉽고 이해하기 쉬운 테스트 조직하는 법 테스트 메소드 내부 구성 테스트 케이스 클래스 구성 테스트 스위트 구성

3. 테스트 스위트 테스트케이스 클래스 테스트 메소드 기본 xUnit메커니즘 테스팅 자동화 도구 사용시 작업 순서 테스트 찾기(521) 테스트 나열(528) 테스트 스위트 객체 생성(513) 테스트 실행기 (502)로 스위트 객체 메소드 실행 테스트 실행기 테스트 코드

4. 적당한 크기의 테스트 메소드 테스트 조건 = { SUT의 시작 상태, 실행 방법, 기대 응답, 종료 상태 } 테스트 메소드= 여러 테스트 코드를 실행

5. 바람직한 테스트 메소드 순차문, 한번에 하나만, SUT격리 순차문 한번에 하나의 조건만 검증 SUT격리

6. 테스트 메소드 조직 전략(1/4) 현실 문제는 두 부분의 사이 어디쯤에 있다. 하나의 테스트 케이스 클래스에 모든 테스트 메소드 하나의 테스트 케이스 클래스에 오직 하나의 테스트 메소드 VS

7. 테스트 메소드 조직 전략(2/4) 클래스별 테스트케이스 클래스 Testcase Class per Class(497) 테스트 메소드가 늘어나면, 테스트 케이스 클래스로 쪼갠다. Refectoring – Extract class와 유사

8. 테스트 메소드 조직 전략(3/4) 기능별 테스트케이스 클래스 기능 중심으로 테스트 케이스 구성 픽스처setup코드 중복 가능성 있음

9. 테스트 메소드 조직 전략(4/4) 픽스처별 테스트케이스 클래스 같은 선조건을 갖는 집합들이 하나의 클래스 테스트조건들이 흩어질 수 있다.

10. 상황에 따른 테스트 메소드 조직 전략 작업의 시작  하나의 테스트 케이스 클래스에서 시작 후, 테스트 코드 리팩토링 상태가 다양한 객체  픽스처별 테스트케이스 클래스 서비스 퍼사드, 고객 테스트  기능별 테스트 케이스 클래스 미리 만든 픽스처(562), 위임설치(541)로픽스처 설치

11. 테스트 이름 정하기 조합형 이름 테스트 패키지 테스트 케이스 클래스 테스트 메소드 이름 어떤것을 알 수 있나? SUT클래스 이름 실행하려는 메소드나 기능 이름 SUT나 그 SUT의존 객체의 상태 관련된것 그 테스트 케이스에 거는 기대 Should throw something…

12. 테스트 스위트 조직하기(1/4) 특정 부분에 관심이 있는 테스트 집단 이름 있는 테스트 스위트 부분 스위트 모든 테스트 스위트들은AllTests에서 실행 가능함.

13. 테스트 스위트 조직하기(2/4) 부분 스위트( xUnit에서는 Test selection 사용) 고객 테스트용 단위 테스트용 부분 스위트의 예 DB에 (종속 / 독립)적인 테스트 스위트 웹서버에(종속 / 독립)적인 테스트 스위트

14. 테스트 스위트 조직하기(3/4) 하나의 테스트 실행하기( 상황) 테스트 메소드 하나 실패 모든 테스트에서 실패한 메소드 호출 Break point를 넣고 싶은데…

15. 테스트 스위트 조직하기(4/4) 하나의 테스트 실행하기( 해결책 ) 중단점 호출 될 때까지 Go 원하는 테스트 말고 다른 테스트 이름 다 바꾸기 Test selection ( xUnit ) 최후의 보루, 하나의 테스트만 실행하는 테스트 스위트 작성

16. 테스트 코드 재사용(1/3) 올바른 테스트 코드 재사용  암묵적 설치, 테스트 유틸리티 메소드(760) 테스트 대역(670) – 여러 테스트에서 재사용, 테스트 주체가 아닌 테스트를 도와주는 Helper개념 여러 fixture에서 테스트 메소드 재사용

17. 테스트 코드 재사용(2/3) 테스트 유틸리티 메소드 위치 SUT의 객체 타입에 독립적인 여러 Test case에서 사용 도메인 패키지별Test Helper생성

18. 테스트 코드 재사용(3/3) 테스트 케이스 상속과 재사용 부모 클래스의 테스트 유틸리티 메소드를 사용하기 위한 상속 프레임워크와 프레임워크 플러그인 테스트를 위한 상속

19. 테스트 파일 구성(1/3) 내장 자체 테스트 제품 코드 안에 테스트 코드 포함 불필요한 메모리 공간 소비

20. 테스트 파일 구성(2/3) 테스트 패키지를 제품 패키지와 따로 두는 경우 같은 소스 폴더 + 테스트 패키지 형제 소스 트리 + 같은 패키지 빌드 타임에 테스트 코드를 컴파일 하지 않도록 해야 함.

21. 테스트 파일 구성(3/3) 테스트 의존 제품코드에 테스트를 위한 코드 기계적으로 제거 불가능함 사람이 코드를 확인하면서 지워줘야 함

22. 정리 언제나 통하는 정답은 없다 가이드라인 테스트 메소드: 한번에 하나의 테스트 코드 작성, 순차적인 코드 작성 테스트 케이스 클래스 : 테스트 메소드가 많아지면 클래스로 분리 테스트 이름은 의도가 드러나도록 명확히 작성 테스트 스위트: 목적에 맞게 여러 스위트로 나누어서 작성 테스트 코드 재사용 : 코드 중복  유지보수 비용증가, 테스트 유틸리티 클래스 적극 활용 테스트 파일 구성 : 가급적이면 제품코드에 테스트코드가 들어가지 않도록 배포

23. 끝