3. 간단한 테스트 자동화 전략 개발 프로세스 + 고객 테스트 + 단위 테스트 + 테스트하기 쉬운 설계 + 테스트 구성 3 개발 프로세스 고객 테스트 단위테스트 테스트하기 쉬운 설계 테스트 조직 테스트 자동화 전략
4. 개발 프로세스 4 소프트웨어 작성 전에 만들어야 어떠한 상태가 성공인가에 대해 의견 일치를 볼 수 있다. 고객 테스트 스위트(suite)를 가장먼저 자동화하여, Storytest-Driven Development 을 하기위해 노력 테스트는 언제 만들지 무엇 먼저 초록 막대 유지하기 적어도 “고객 테스트” 가 커버하지 못하는 공간에 대한 “단위 테스트”. 코드 체크인 하기 전에 “단위 테스트” 통과 시키기
5. 개발 프로세스 - con’t 5 소프트웨어를 테스트 가능하게. 단위 테스트 결과적으로 -> 잘 정의된 객체와, 비즈니스 로직에만 집중 ( 비즈니스 로직 테스트는 데이터베이스에의 의존을 최소화) 테스트 주도 개발 의 장점 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’t 9 실행시킬 방법을 찾지 못해 테스트 안 된 코드(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’t 11 애플리케이션이 너무 복잡하거나 다른 프로젝트에서 재사용될 컴퍼넌트의 테스트 컴퍼넌트가 의존하는 다른 컴퍼넌트를 대체 하려면 테스트 대역 사용 - 의존 주입(Dependency Injection) - 의존찾기(Dependency Loopup) - 상속받은 싱글턴(Subclassed Singleton) Component Test
12.
13. 패키지나 네임스페이스 안에 넣는 방식으로 테스트 스위트 객체에 차례차례 추가 가능.테스트 케이스 클레스에 테스트 메소드가 많아지면 ** 암묵적 설치 -> “픽스처별 테스트 케이스 클레스”를 사용시 픽스처 설치 코드를 setUp메소드에 옮겨 놓는것.
14. 정리 1장은 간단한 소개일 뿐. 2장~14장 : 1장 내용의 상세화 자세히 알고 싶은 패턴이나 냄새는 2부나 3부 13
