xUnit Test Pattern<br />	- 1장 – 간단하게 둘러보기<br />강효원<br />
1장은……<br />책 전체에 대한 간략한 소개.<br />2<br />
간단한 테스트 자동화 전략<br />개발 프로세스 + 고객 테스트 + 단위 테스트 + 테스트하기 쉬운 설계 + 테스트 구성<br />3<br />개발 프로세스<br />고객 테스트<br />단위테스트<br />테스트하기...
개발 프로세스<br />4<br />소프트웨어 작성 전에 만들어야 <br />어떠한 상태가 성공인가에 대해 의견 일치를 볼 수 있다.<br />고객 테스트 스위트(suite)를 가장먼저 자동화하여, <br />Story...
개발 프로세스 - con’t<br />5<br />소프트웨어를 테스트 가능하게.<br />단위 테스트<br />결과적으로 -> 잘 정의된 객체와, 비즈니스 로직에만 집중<br />( 비즈니스 로직 테스트는 데이터베이스에...
고객 테스트<br />6<br />고객이 정말 원하는, 성공했을 때 어떻게 보여야 하는가에 대한 정의<br />고객 테스트<br />자동화 방법<br />스크립트 기반 테스트(Scripted Test)<br />데이터 ...
고객 테스트<br />7<br />서비스 퍼사드(Service Façade) <br />피하 테스트(Subcutaneous Testing) , UI 건너 뛰기.<br />비즈니스 로직을 단순한 인터페이스로 캡슐화, <b...
효과적인 테스트가 되려면<br />단위 테스트<br />8<br />완전 자동 테스트 : public 인터페이스로 왕복 테스트(Round-Trip Test)<br />단일 조건 테스트 : 결함 국소화를 위해 하나의 시나...
단위 테스트 – con’t<br />9<br />실행시킬 방법을 찾지 못해 테스트 안 된 코드(Untested Code) 가 있다면 <br />테스트 스텁을 사용해 SUT의 간접 입력을 제어<br />테스트스텁(Test...
테스트하기 쉬운 설계<br />10<br />복잡하고 에러가 나기 쉬운 해체 코드ㅠ.ㅠ<br />느린 테스트 ( DB 접근, Disk IO)<br />GUI 프레임워크랑 그래픽 객체 관리 ㅠ.ㅠ<br />레이어 아키텍처...
테스트하기 쉬운 설계- con’t<br />11<br />애플리케이션이 너무 복잡하거나 다른 프로젝트에서 재사용될 컴퍼넌트의 테스트<br />컴퍼넌트가 의존하는 다른 컴퍼넌트를 대체 하려면 테스트 대역 사용<br /> ...
테스트 조직<br />12<br />기능별 테스트케이스 클래스(Testcase Class per Fiature)<br />픽스쳐별 테스트 케이스 클래스(Testcase Class per Fixture)<br />테스트 ...
패키지나 네임스페이스 안에 넣는 방식으로 테스트 스위트 객체에 차례차례 추가 가능.</li></ul>테스트 케이스 클레스에<br />테스트 메소드가 많아지면<br />** 암묵적 설치 -> “픽스처별 테스트 케이스 클레...
Upcoming SlideShare
Loading in...5
×

X unittestpattern 1장_아꿈사

1,081

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,081
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

X unittestpattern 1장_아꿈사

  1. 1. xUnit Test Pattern<br /> - 1장 – 간단하게 둘러보기<br />강효원<br />
  2. 2. 1장은……<br />책 전체에 대한 간략한 소개.<br />2<br />
  3. 3. 간단한 테스트 자동화 전략<br />개발 프로세스 + 고객 테스트 + 단위 테스트 + 테스트하기 쉬운 설계 + 테스트 구성<br />3<br />개발 프로세스<br />고객 테스트<br />단위테스트<br />테스트하기 쉬운 설계<br />테스트 조직<br />테스트 자동화 전략<br />
  4. 4. 개발 프로세스<br />4<br />소프트웨어 작성 전에 만들어야 <br />어떠한 상태가 성공인가에 대해 의견 일치를 볼 수 있다.<br />고객 테스트 스위트(suite)를 가장먼저 자동화하여, <br />Storytest-Driven Development 을 하기위해 노력<br />테스트는 언제 만들지<br />무엇 먼저<br />초록 막대 유지하기<br />적어도 “고객 테스트” 가 커버하지 못하는 <br />공간에 대한 “단위 테스트”.<br />코드 체크인 하기 전에 “단위 테스트” 통과 시키기<br />
  5. 5. 개발 프로세스 - con’t<br />5<br />소프트웨어를 테스트 가능하게.<br />단위 테스트<br />결과적으로 -> 잘 정의된 객체와, 비즈니스 로직에만 집중<br />( 비즈니스 로직 테스트는 데이터베이스에의 의존을 최소화)<br />테스트 주도 개발 의 장점<br />IF<br />고객이 최종적인 성공 상태를 정의하지 못한다거나, <br />고객 간에(ex 실무자 와 관리자) 성공 상태의 정의가 다르다면?<br />
  6. 6. 고객 테스트<br />6<br />고객이 정말 원하는, 성공했을 때 어떻게 보여야 하는가에 대한 정의<br />고객 테스트<br />자동화 방법<br />스크립트 기반 테스트(Scripted Test)<br />데이터 주도 테스트(Data-Driven Test)<br />기록 테스트 (Recorded Test) ( 깨지기 쉬운 테스트, Frangile Test)<br />IF<br />애매한 테스트<br />결함 국소화 를 제공하지 못함<br />테스트가 길어지면?<br />멀 하려던 걸까… 어디가 문제란 걸까 ㅠ.ㅠ<br />
  7. 7. 고객 테스트<br />7<br />서비스 퍼사드(Service Façade) <br />피하 테스트(Subcutaneous Testing) , UI 건너 뛰기.<br />비즈니스 로직을 단순한 인터페이스로 캡슐화, <br />Test Fixture <br />테스트의 시작점,<br />신선한 픽스처(Fresh Fixture)-> 서로 반응하는 테스트(Interacting Test) 을막아줌<br />테스트 대역(Test Double)<br />가짜 객체(Fake Object)<br />엮인 테스트-> 서로 반응하는 테스트<br />다음 장에서 다른 분들이 잘 해주실 거에요…..<br />
  8. 8. 효과적인 테스트가 되려면<br />단위 테스트<br />8<br />완전 자동 테스트 : public 인터페이스로 왕복 테스트(Round-Trip Test)<br />단일 조건 테스트 : 결함 국소화를 위해 하나의 시나리오 안에서 하나의 메소드나 객체만 실행<br />문서로서의 테스트 : 4단계 테스트의 각 부분을 쉽게 알 수 있도록테스트 작성<br />신선한 픽스처<br />자체 검사<br />서로 반응하는 테스트나 픽스처 해체를 고민하지 않아도 됨<br />테스트 대상 클래스별 테스트 케이스 클래스 생성<br />위임 설치를 통한 최소 픽스처(Minimal Fixture)생성,<br />최소 픽스처에는 적절한 이름의 생성 메서드<br />하나 이상의 기대 객체(Expected Object)와 테스트 대상 시스템(System Under Test,SUT)이 <br />리턴하는 실제 객채와 비교 하는 방법으로 검사, <br />내장된 동등 단언문(Equality Assertion) 이나 맞춤 단언문(Custom Assertion) 사용<br />검증 메소드: 여러 테스트에서 같은 결과가 나올 것으로 예상되면 검증 로직을 뽑아내어 결과 표현.<br />
  9. 9. 단위 테스트 – con’t<br />9<br />실행시킬 방법을 찾지 못해 테스트 안 된 코드(Untested Code) 가 있다면 <br />테스트 스텁을 사용해 SUT의 간접 입력을 제어<br />테스트스텁(Test Stub)<br />모의 객체(Mock Object)<br />Public 인터페이스로 확인할 수 없는 경우 테스트 안된 요구 사항(Untested Requirement)이 생길 수 있다.<br />이럴 때 모의 객체(Mock Object) 로 SUT 의 간접 출력을 가로채어 검증<br />
  10. 10. 테스트하기 쉬운 설계<br />10<br />복잡하고 에러가 나기 쉬운 해체 코드ㅠ.ㅠ<br />느린 테스트 ( DB 접근, Disk IO)<br />GUI 프레임워크랑 그래픽 객체 관리 ㅠ.ㅠ<br />레이어 아키텍처(Layered Architecture) 의 도입<br />- 테스트 자동화가 훨씬 간단해짐.<br />- 비즈니스 로직을 쉽게 테스트 하려면, 적어도 데이타베이스나<br /> 사용자 인터페이스와 분리 해야 한다.<br />데이터베이스 샌드박스(Database Sandbox)와의 의존을 최소화 하기<br />위해 대부분의 테스트가 메모리에 있는 객체만 쓰도록 작성<br />GUI 로직을비주얼 클래스(Visual Classses)와 격리<br />모든 결정을 비 GUI 클레스에 위임하는 대강만든 다이얼로그(Humble Dialog)도입<br />자원 해체 코드작성 불 필요.<br />빨라진테스트<br />GUI 로직이 의존하는 프레임워크나 <br />그래픽 객체 없이 GUI 로직 테스트 가능<br />
  11. 11. 테스트하기 쉬운 설계- con’t<br />11<br />애플리케이션이 너무 복잡하거나 다른 프로젝트에서 재사용될 컴퍼넌트의 테스트<br />컴퍼넌트가 의존하는 다른 컴퍼넌트를 대체 하려면 테스트 대역 사용<br /> - 의존 주입(Dependency Injection)<br /> - 의존찾기(Dependency Loopup)<br /> - 상속받은 싱글턴(Subclassed Singleton)<br />Component Test<br />
  12. 12. 테스트 조직<br />12<br />기능별 테스트케이스 클래스(Testcase Class per Fiature)<br />픽스쳐별 테스트 케이스 클래스(Testcase Class per Fixture)<br />테스트 케이스 클래스 들을 위한 테스트 스위트 객체를 하나로 모아 <br />테스트 스위트 객체(??) 작성 하면 <br /><ul><li>원래의 테스트케이스 클래스들의 모든 테스트를 담고 있는 “스위트들의스위트(Suite of Suites)”
  13. 13. 패키지나 네임스페이스 안에 넣는 방식으로 테스트 스위트 객체에 차례차례 추가 가능.</li></ul>테스트 케이스 클레스에<br />테스트 메소드가 많아지면<br />** 암묵적 설치 -> “픽스처별 테스트 케이스 클레스”를 사용시 픽스처 설치 코드를 setUp메소드에 옮겨 놓는것.<br />
  14. 14. 정리<br />1장은 간단한 소개일 뿐.<br />2장~14장 : 1장 내용의 상세화<br />자세히 알고 싶은 패턴이나 냄새는 2부나 3부<br />13<br />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×