Your SlideShare is downloading. ×
Test Driven Development<br />TDD<br />
2002년피보나치 수열 TDD로 짜는 동영상<br />
main()<br />
Edit & Pray<br />
2009년전사적 QP활동Code Corverage<br />
Legacy Code에서 개발하기<br />
TDD 제대로 배워보기<br />
assert( 개발에서 만드는 테스트의 종류를 파악하고 장단점을 이해한다 );<br />
개발자라면<br />테스트도 코드로!<br />
<ul><li>장점</li></ul>쉽다간편하다<br />테스트 불가능한 경우 거의 없음<br /><ul><li>단점</li></ul>휘발성<br />재현의 어려움<br />수동 테스트<br />
<ul><li>장점</li></ul>여러 번 수행 가능하다.<br />기존 테스트는 새 테스트를 작성하는 발판이 된다<br />코드를 통한 도큐먼트 & 커뮤니케이션 <br /><ul><li>단점</li></ul>기술, ...
assert( TDD가 무엇인지 안다 );<br />
Test the program before you write it.[1]<br />[1] 『테스트 주도 개발』<br />
<ul><li>오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.
중복을 제거한다.</li></ul>TDD에서는<br />
assert( 테스트 범주를 이해한다 );<br />
<ul><li>최소 실행 단위, 보통 함수 하나에 대한 테스트[1]
외부의 의존성을 배제한 테스트</li></ul>Unit Test<br />[1] http://en.wikipedia.org/wiki/Unit_testing<br />
<ul><li>개별 모듈을 결합하여 그룹의 테스트[1]
DB, 네트웍 리소스를 활용한 테스트</li></ul>Integration Test<br />[1] http://en.wikipedia.org/wiki/Integration_testing<br />
<ul><li>전체 소프트웨어 시스템을 실행시키고 진행하는 테스트
기능/시나리오 테스트</li></ul>System Test[1]<br />[1] 『지속적 통합: 소프트웨어 품질을 높이고 위험을 줄이기』<br />
테스트 범주 별 도구[1]<br />[1] 『지속적 통합: 소프트웨어 품질을 높이고 위험을 줄이기』<br />
assert( Mock Object를 사용해야 하는 경우를 안다);<br />
<ul><li>代役
임시의 가상 구현체</li></ul>Test Double<br />[그림] http://msdn.microsoft.com/ko-kr/magazine/cc163358.aspx<br />
<ul><li>테스트 대상이 가진 ‘의존성’을 배제하고 테스트 케이스를 작성 할 때</li></ul>환경 구축이 필요한 경우<br />의존적인 라이브러리가 테스트 시간을 많이 소요할 경우<br />특정 순간이나 이벤트에...
assert( TDD를 시도해보면 무언가 장점을 얻을 수 있겠다는 느낌이 있다);<br />
메일 발송 배치 개발<br /><ul><li>메일Pool에 미발송 메일이 있는지 확인한다.
미발송 메일이 있을 경우, 메일서버로 발송을 요청한다.
발송이 성공하면,  메일Pool에 결과를 저장한다.</li></li></ul><li><ul><li>테스트 대상 소스와 테스트 클래스를 같은 위치로
테스트 클래스는 하위 패키지로
Upcoming SlideShare
Loading in...5
×

Tdd

753

Published on

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

No Downloads
Views
Total Views
753
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Tdd"

  1. 1. Test Driven Development<br />TDD<br />
  2. 2. 2002년피보나치 수열 TDD로 짜는 동영상<br />
  3. 3. main()<br />
  4. 4. Edit & Pray<br />
  5. 5. 2009년전사적 QP활동Code Corverage<br />
  6. 6. Legacy Code에서 개발하기<br />
  7. 7. TDD 제대로 배워보기<br />
  8. 8. assert( 개발에서 만드는 테스트의 종류를 파악하고 장단점을 이해한다 );<br />
  9. 9.
  10. 10.
  11. 11. 개발자라면<br />테스트도 코드로!<br />
  12. 12. <ul><li>장점</li></ul>쉽다간편하다<br />테스트 불가능한 경우 거의 없음<br /><ul><li>단점</li></ul>휘발성<br />재현의 어려움<br />수동 테스트<br />
  13. 13. <ul><li>장점</li></ul>여러 번 수행 가능하다.<br />기존 테스트는 새 테스트를 작성하는 발판이 된다<br />코드를 통한 도큐먼트 & 커뮤니케이션 <br /><ul><li>단점</li></ul>기술, 노하우의 필요<br />자동 테스트<br />
  14. 14. assert( TDD가 무엇인지 안다 );<br />
  15. 15. Test the program before you write it.[1]<br />[1] 『테스트 주도 개발』<br />
  16. 16.
  17. 17. <ul><li>오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.
  18. 18. 중복을 제거한다.</li></ul>TDD에서는<br />
  19. 19. assert( 테스트 범주를 이해한다 );<br />
  20. 20. <ul><li>최소 실행 단위, 보통 함수 하나에 대한 테스트[1]
  21. 21. 외부의 의존성을 배제한 테스트</li></ul>Unit Test<br />[1] http://en.wikipedia.org/wiki/Unit_testing<br />
  22. 22. <ul><li>개별 모듈을 결합하여 그룹의 테스트[1]
  23. 23. DB, 네트웍 리소스를 활용한 테스트</li></ul>Integration Test<br />[1] http://en.wikipedia.org/wiki/Integration_testing<br />
  24. 24. <ul><li>전체 소프트웨어 시스템을 실행시키고 진행하는 테스트
  25. 25. 기능/시나리오 테스트</li></ul>System Test[1]<br />[1] 『지속적 통합: 소프트웨어 품질을 높이고 위험을 줄이기』<br />
  26. 26. 테스트 범주 별 도구[1]<br />[1] 『지속적 통합: 소프트웨어 품질을 높이고 위험을 줄이기』<br />
  27. 27. assert( Mock Object를 사용해야 하는 경우를 안다);<br />
  28. 28. <ul><li>代役
  29. 29. 임시의 가상 구현체</li></ul>Test Double<br />[그림] http://msdn.microsoft.com/ko-kr/magazine/cc163358.aspx<br />
  30. 30. <ul><li>테스트 대상이 가진 ‘의존성’을 배제하고 테스트 케이스를 작성 할 때</li></ul>환경 구축이 필요한 경우<br />의존적인 라이브러리가 테스트 시간을 많이 소요할 경우<br />특정 순간이나 이벤트에 의존적인 경우<br />언제 Mock객체를 만들 것인가?<br />
  31. 31. assert( TDD를 시도해보면 무언가 장점을 얻을 수 있겠다는 느낌이 있다);<br />
  32. 32. 메일 발송 배치 개발<br /><ul><li>메일Pool에 미발송 메일이 있는지 확인한다.
  33. 33. 미발송 메일이 있을 경우, 메일서버로 발송을 요청한다.
  34. 34. 발송이 성공하면, 메일Pool에 결과를 저장한다.</li></li></ul><li><ul><li>테스트 대상 소스와 테스트 클래스를 같은 위치로
  35. 35. 테스트 클래스는 하위 패키지로
  36. 36. 최상위 패키지를 분리
  37. 37. 소스 폴더는 다르게, 패키지는 동일, 컴파일된 클래스는 각각 다른 곳으로
  38. 38. 테스트를 프로젝트로 분리</li></ul>테스트 케이스 클래스의 위치[1]<br />[1] 『테스트 주도 개발 : 고품질 쾌속개발을 위한 TDD 실천법과 도구』<br />
  39. 39. MoreUnit<br />
  40. 40. Mockito<br /><ul><li>기본 사용법 </li></ul>Mock 객체 만들기<br />예상값 지정<br />테스트에 사용할 스텁 만들기<br />검증<br /><ul><li>특징</li></ul>void 메소드를 stub으로만들기<br />실제 객체를 stub으로만들기 : spy<br />Behavior-Driven Development 스타일 지원<br />
  41. 41. assert( TDD의 장점을 이해한다 );<br />
  42. 42. <ul><li>개발의 방향을 잃지 않게 유지해준다.
  43. 43. 품질 높은 소프트웨어 모듈 보유하게 된다.
  44. 44. 자동화된 단위 테스트 케이스를 갖게 된다.
  45. 45. 사용설명서 & 의사소통 수단으로 사용한다.
  46. 46. 리팩토링이 용이하다.
  47. 47. 보다 자주 성공을 경험하게 한다.</li></ul>TDD의 장점<br />
  48. 48.
  49. 49.
  50. 50. Regression Testassert( 개발에서 만드는 테스트의 종류를 파악하고 장단점을 이해한다 );assert( TDD가 무엇인지 안다 );assert( 테스트 범주를 이해한다 );assert( Mock Object를 사용해야 하는 경우를 안다);assert( TDD를 시도해보면 무언가 장점을 얻을 수 있겠다는 느낌이 있다);assert( TDD의 장점을 이해한다 );<br />

×