1. xUnit Test Pattern - 1장 – 간단하게 둘러보기강효원

2. 1장은……책 전체에 대한 간략한 소개.2

3. 간단한 테스트 자동화 전략개발 프로세스 + 고객 테스트 + 단위 테스트 + 테스트하기 쉬운 설계 + 테스트 구성3개발 프로세스고객 테스트단위테스트테스트하기 쉬운 설계테스트 조직테스트 자동화 전략

4. 개발 프로세스4소프트웨어 작성 전에 만들어야 어떠한 상태가 성공인가에 대해 의견 일치를 볼 수 있다.고객 테스트 스위트(suite)를 가장먼저 자동화하여, Storytest-Driven Development 을 하기위해 노력테스트는 언제 만들지무엇 먼저초록 막대 유지하기적어도 “고객 테스트” 가 커버하지 못하는 공간에 대한 “단위 테스트”.코드 체크인 하기 전에 “단위 테스트” 통과 시키기

5. 개발 프로세스 - con’t5소프트웨어를 테스트 가능하게.단위 테스트결과적으로 -> 잘 정의된 객체와, 비즈니스 로직에만 집중( 비즈니스 로직 테스트는 데이터베이스에의 의존을 최소화)테스트 주도 개발 의 장점IF고객이 최종적인 성공 상태를 정의하지 못한다거나, 고객 간에(ex 실무자 와 관리자) 성공 상태의 정의가 다르다면?

6. 고객 테스트6고객이 정말 원하는, 성공했을 때 어떻게 보여야 하는가에 대한 정의고객 테스트자동화 방법스크립트 기반 테스트(Scripted Test)데이터 주도 테스트(Data-Driven Test)기록 테스트 (Recorded Test) ( 깨지기 쉬운 테스트, Frangile Test)IF애매한 테스트결함 국소화 를 제공하지 못함테스트가 길어지면?멀 하려던 걸까… 어디가 문제란 걸까 ㅠ.ㅠ

7. 고객 테스트7서비스 퍼사드(Service Façade) 피하 테스트(Subcutaneous Testing) , UI 건너 뛰기.비즈니스 로직을 단순한 인터페이스로 캡슐화, Test Fixture 테스트의 시작점,신선한 픽스처(Fresh Fixture)-> 서로 반응하는 테스트(Interacting Test) 을막아줌테스트 대역(Test Double)가짜 객체(Fake Object)엮인 테스트-> 서로 반응하는 테스트다음 장에서 다른 분들이 잘 해주실 거에요…..

8. 효과적인 테스트가 되려면단위 테스트8완전 자동 테스트 : public 인터페이스로 왕복 테스트(Round-Trip Test)단일 조건 테스트 : 결함 국소화를 위해 하나의 시나리오 안에서 하나의 메소드나 객체만 실행문서로서의 테스트 : 4단계 테스트의 각 부분을 쉽게 알 수 있도록테스트 작성신선한 픽스처자체 검사서로 반응하는 테스트나 픽스처 해체를 고민하지 않아도 됨테스트 대상 클래스별 테스트 케이스 클래스 생성위임 설치를 통한 최소 픽스처(Minimal Fixture)생성,최소 픽스처에는 적절한 이름의 생성 메서드하나 이상의 기대 객체(Expected Object)와 테스트 대상 시스템(System Under Test,SUT)이 리턴하는 실제 객채와 비교 하는 방법으로 검사, 내장된 동등 단언문(Equality Assertion) 이나 맞춤 단언문(Custom Assertion) 사용검증 메소드: 여러 테스트에서 같은 결과가 나올 것으로 예상되면 검증 로직을 뽑아내어 결과 표현.

9. 단위 테스트 – con’t9실행시킬 방법을 찾지 못해 테스트 안 된 코드(Untested Code) 가 있다면 테스트 스텁을 사용해 SUT의 간접 입력을 제어테스트스텁(Test Stub)모의 객체(Mock Object)Public 인터페이스로 확인할 수 없는 경우 테스트 안된 요구 사항(Untested Requirement)이 생길 수 있다.이럴 때 모의 객체(Mock Object) 로 SUT 의 간접 출력을 가로채어 검증

10. 테스트하기 쉬운 설계10복잡하고 에러가 나기 쉬운 해체 코드ㅠ.ㅠ느린 테스트 ( DB 접근, Disk IO)GUI 프레임워크랑 그래픽 객체 관리 ㅠ.ㅠ레이어 아키텍처(Layered Architecture) 의 도입- 테스트 자동화가 훨씬 간단해짐.- 비즈니스 로직을 쉽게 테스트 하려면, 적어도 데이타베이스나 사용자 인터페이스와 분리 해야 한다.데이터베이스 샌드박스(Database Sandbox)와의 의존을 최소화 하기위해 대부분의 테스트가 메모리에 있는 객체만 쓰도록 작성GUI 로직을비주얼 클래스(Visual Classses)와 격리모든 결정을 비 GUI 클레스에 위임하는 대강만든 다이얼로그(Humble Dialog)도입자원 해체 코드작성 불 필요.빨라진테스트GUI 로직이 의존하는 프레임워크나 그래픽 객체 없이 GUI 로직 테스트 가능

11. 테스트하기 쉬운 설계- con’t11애플리케이션이 너무 복잡하거나 다른 프로젝트에서 재사용될 컴퍼넌트의 테스트컴퍼넌트가 의존하는 다른 컴퍼넌트를 대체 하려면 테스트 대역 사용 - 의존 주입(Dependency Injection) - 의존찾기(Dependency Loopup) - 상속받은 싱글턴(Subclassed Singleton)Component Test

12. 테스트 조직12기능별 테스트케이스 클래스(Testcase Class per Fiature)픽스쳐별 테스트 케이스 클래스(Testcase Class per Fixture)테스트 케이스 클래스 들을 위한 테스트 스위트 객체를 하나로 모아 테스트 스위트 객체(??) 작성 하면 원래의 테스트케이스 클래스들의 모든 테스트를 담고 있는 “스위트들의스위트(Suite of Suites)”

13. 패키지나 네임스페이스 안에 넣는 방식으로 테스트 스위트 객체에 차례차례 추가 가능.테스트 케이스 클레스에테스트 메소드가 많아지면** 암묵적 설치 -> “픽스처별 테스트 케이스 클레스”를 사용시 픽스처 설치 코드를 setUp메소드에 옮겨 놓는것.

14. 정리1장은 간단한 소개일 뿐.2장~14장 : 1장 내용의 상세화자세히 알고 싶은 패턴이나 냄새는 2부나 3부13