• Like
xUnitTestPattern/chapter3
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

xUnitTestPattern/chapter3

  • 707 views
Published

 

Published in Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
707
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
5
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 3 장 테스트 자동화의 목표 장 수 윤 ( [email_address] ) 2010. 07. 24 XUNIT 테스트 패턴
  • 2. 목차
    • 개요
    • 테스트 자동화 경제학
    • 테스트 자동화의 목표
  • 3. 개요
    • 성공적인 자동 단위 테스트와 고객 테스트를 구축하기 위해 추구해야 할 목표
    • 테스트를 자동화하려는 이유
    • 테스트 자동화의 목표
  • 4. 테스트 자동화 경제학
    • 테스트 자동화가 개발비용을 늘리지 않으므로 테스트 자동화는 ‘당연’한 것
    • 수동 단위테스트환경에서의 버그 발견시점 지연으로 인한 처리비용 > 자동테스트 구축 및 유지 보수 비용
    자동 테스트에 드는 노력 제품 코드 개발에 드는 노력 노력 증가 ( 고비 ) 노력 감소 줄어든 노력 초기 노력 시간 노력 증가 ( 고비 ) 계속되는 노력 줄어든 노력 초기 노력 시간 좋은 예 나쁜 예
  • 5. 테스트 자동화의 목표 1. 테스트는 품질 향상 에 도움이 돼야 한다 2. 테스트는 SUT 를 이해 하는 데 도움이 돼야 한다 3. 테스트는 위험을 줄여야 ( 추가하지도 않아야 ) 한다 4. 테스트는 실행하기 쉬워야 한다 5. 테스트는 만들고 유지하기 쉬워야 한다 6. 테스트는 두 가지 이유로 복잡 해진다 7. 시스템이 발전하는 동안 테스트에 필요한 유지 보수 비용이 최 소화돼야 한다
  • 6. 1. 테스트는 품질 향상 에 도움이 돼야 한다
    • 명세로서의 테스트
      • 사용자가 SUT 를 사용하는 방식을 반영
      • 테스트 작성과정에서 명세품질이 향상
    • 버그 퇴치
      • 회귀 테스트로 인한 방충효과
    • 결함 국소화
      • 단위 테스트 하나당 하나의 동작만 테스트 한다면 테스트 실패 시 버그가 무엇인지 바로 알아 낼 수 있다
  • 7. 2. 테스트는 SUT 를 이해 하는 데 도움이 돼야 한다
    • 문서로서의 테스트
      • 테스트 코드 자체가 시스템이 어떻게 동작해야 하는지 알려주는 문서 역할
  • 8. 3. 테스트는 위험을 줄여야 ( 추가하지도 않아야 ) 한다
    • 안전망으로서의 테스트
      • 훨씬 실험적인 방식으로 S/W 변경을 가능하게 해준다
    • 해를 끼치지 않을 것
      • 제품코드에 테스트 코드 출입금지
  • 9. 4. 테스트는 실행하기 쉬워야 한다
    • * 자동테스트 실행이 정말 쉬워야만 사람들이 자주 실행할 것이다 .
    • 완전 자동 테스트
      • without 수동조정
    • 자체 검사 테스트
      • 할리우드 원칙 ( 통과하지 못했을 때에만 알려준다 )
    • 반복되는 테스트
      • 최대한 자주 실행될 수 있어야
    • 독립적인 테스트 ( 이상적 )
  • 10. 5. 테스트는 만들고 유지하기 쉬워야 한다
    • 테스트를 빨리 읽을 수 있도록 쉽게 유지해야
    • ‘ 테스트 오버랩 최소화하기’를 통해 시스템의 변경에 대한 영향 최소화
  • 11. 6. 테스트는 두 가지 이유로 복잡 해진다
    • 두 가지 이유
      • 너무 많은 기능을 하나의 테스트에서
      • 표현수단과 의도간 간극이 너무 크다
    • 단순한 테스트
      • 한 번에 하나만
      • 테스트 메소드는 SUT 가 한 경로만 실행하게 해야
    • 표현이 풍부한 테스트
      • 표현의 간극은 ‘테스트 유틸리티 메소드’로 해결
    • 관심의 분리
      • 테스트 코드를 제품 코드로부터 분리
      • 각 테스트는 한가지 관심에만 집중
  • 12. 7. 테스트에 필요한 유지 보수 비용이 최소화돼야 한다
    • 견고한 테스트
      • 제품의 변경을 피할 수 없는 현실
      • 하나를 변경했을 때 영향 받는 테스트의 수가 최소가 되도록 해야
      • 테스트끼리 최대한 적게 겹쳐야
      • 변화요인이 많은 부분을 테스트 유틸리티 메소드로 캡슐화
  • 13. 감사합니다