xUnitTestPattern/chapter12

1,083 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,083
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

xUnitTestPattern/chapter12

  1. 1. 12장 테스트 조직하기<br />아키텍트를 꿈꾸는 사람들 오전스터디<br />2010. 8. 7.<br />전효성<br />
  2. 2. Goal<br />찾기 쉽고 이해하기 쉬운 테스트 조직하는 법<br />테스트 메소드 내부 구성<br />테스트 케이스 클래스 구성<br />테스트 스위트 구성<br />
  3. 3. 테스트 스위트<br />테스트케이스 클래스<br />테스트 메소드<br />기본 xUnit메커니즘<br />테스팅 자동화 도구 사용시 작업 순서<br />테스트 찾기(521)<br />테스트 나열(528)<br />테스트 스위트 객체 생성(513)<br />테스트 실행기 (502)로 스위트 객체 메소드 실행<br />테스트 실행기<br />테스트 코드<br />
  4. 4. 적당한 크기의 테스트 메소드<br />테스트 조건 = { SUT의 시작 상태, 실행 방법, 기대 응답, 종료 상태 }<br />테스트 메소드= 여러 테스트 코드를 실행<br />
  5. 5. 바람직한 테스트 메소드<br />순차문, 한번에 하나만, SUT격리<br />순차문<br />한번에 하나의 조건만 검증<br />SUT격리<br />
  6. 6. 테스트 메소드 조직 전략(1/4)<br />현실 문제는 두 부분의 사이 어디쯤에 있다.<br />하나의 테스트 케이스 클래스에<br />모든 테스트 메소드<br />하나의 테스트 케이스 클래스에<br />오직 하나의 테스트 메소드<br />VS<br />
  7. 7. 테스트 메소드 조직 전략(2/4)<br />클래스별 테스트케이스 클래스<br />Testcase Class per Class(497)<br />테스트 메소드가 늘어나면, 테스트 케이스 클래스로 쪼갠다.<br />Refectoring – Extract class와 유사<br />
  8. 8. 테스트 메소드 조직 전략(3/4)<br />기능별 테스트케이스 클래스<br />기능 중심으로 테스트 케이스 구성<br />픽스처setup코드 중복 가능성 있음<br />
  9. 9. 테스트 메소드 조직 전략(4/4)<br />픽스처별 테스트케이스 클래스<br />같은 선조건을 갖는 집합들이 하나의 클래스<br />테스트조건들이 흩어질 수 있다.<br />
  10. 10. 상황에 따른 테스트 메소드 조직 전략<br />작업의 시작  하나의 테스트 케이스 클래스에서 시작 후, 테스트 코드 리팩토링<br />상태가 다양한 객체  픽스처별 테스트케이스 클래스<br />서비스 퍼사드, 고객 테스트  기능별 테스트 케이스 클래스<br />미리 만든 픽스처(562), 위임설치(541)로픽스처 설치<br />
  11. 11. 테스트 이름 정하기<br />조합형 이름<br />테스트 패키지<br />테스트 케이스 클래스<br />테스트 메소드 이름<br />어떤것을 알 수 있나?<br /> SUT클래스 이름<br />실행하려는 메소드나 기능 이름<br />SUT나 그 SUT의존 객체의 상태 관련된것<br />그 테스트 케이스에 거는 기대<br />Should throw something…<br />
  12. 12. 테스트 스위트 조직하기(1/4)<br />특정 부분에 관심이 있는 테스트 집단<br />이름 있는 테스트 스위트<br />부분 스위트<br />모든 테스트 스위트들은AllTests에서 실행 가능함.<br />
  13. 13. 테스트 스위트 조직하기(2/4)<br />부분 스위트( xUnit에서는 Test selection 사용)<br />고객 테스트용<br />단위 테스트용<br />부분 스위트의 예<br />DB에 (종속 / 독립)적인 테스트 스위트<br />웹서버에(종속 / 독립)적인 테스트 스위트<br />
  14. 14. 테스트 스위트 조직하기(3/4)<br />하나의 테스트 실행하기( 상황)<br />테스트 메소드 하나 실패<br />모든 테스트에서 실패한 메소드 호출<br />Break point를 넣고 싶은데…<br />
  15. 15. 테스트 스위트 조직하기(4/4)<br />하나의 테스트 실행하기( 해결책 )<br />중단점 호출 될 때까지 Go<br />원하는 테스트 말고 다른 테스트 이름 다 바꾸기<br />Test selection ( xUnit )<br />최후의 보루, 하나의 테스트만 실행하는 테스트 스위트 작성<br />
  16. 16. 테스트 코드 재사용(1/3)<br />올바른 테스트 코드 재사용  암묵적 설치, 테스트 유틸리티 메소드(760)<br />테스트 대역(670) – 여러 테스트에서 재사용, 테스트 주체가 아닌 테스트를 도와주는 Helper개념<br />여러 fixture에서 테스트 메소드 재사용<br />
  17. 17. 테스트 코드 재사용(2/3)<br />테스트 유틸리티 메소드 위치<br />SUT의 객체 타입에 독립적인<br />여러 Test case에서 사용<br />도메인 패키지별Test Helper생성<br />
  18. 18. 테스트 코드 재사용(3/3)<br />테스트 케이스 상속과 재사용<br />부모 클래스의 테스트 유틸리티 메소드를 사용하기 위한 상속<br />프레임워크와 프레임워크 플러그인 테스트를 위한 상속<br />
  19. 19. 테스트 파일 구성(1/3)<br />내장 자체 테스트<br />제품 코드 안에 테스트 코드 포함<br />불필요한 메모리 공간 소비<br />
  20. 20. 테스트 파일 구성(2/3)<br />테스트 패키지를 제품 패키지와 따로 두는 경우<br />같은 소스 폴더 + 테스트 패키지<br />형제 소스 트리 + 같은 패키지<br />빌드 타임에 테스트 코드를 컴파일 하지 않도록 해야 함.<br />
  21. 21. 테스트 파일 구성(3/3)<br />테스트 의존<br />제품코드에 테스트를 위한 코드<br />기계적으로 제거 불가능함<br />사람이 코드를 확인하면서 지워줘야 함<br />
  22. 22. 정리<br />언제나 통하는 정답은 없다<br />가이드라인<br />테스트 메소드: 한번에 하나의 테스트 코드 작성, 순차적인 코드 작성<br /> 테스트 케이스 클래스 : 테스트 메소드가 많아지면 클래스로 분리<br />테스트 이름은 의도가 드러나도록 명확히 작성<br />테스트 스위트: 목적에 맞게 여러 스위트로 나누어서 작성<br />테스트 코드 재사용 : 코드 중복  유지보수 비용증가, 테스트 유틸리티 클래스 적극 활용<br />테스트 파일 구성 : 가급적이면 제품코드에 테스트코드가 들어가지 않도록 배포<br />
  23. 23. 끝<br />

×