TDD 테스트 주도 개발이며, 하나의 개발 방법론 입니다.
- TDD는 반복 테스트을 이용한 소프트웨어 개발법이다. 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 소프트웨어를 구현한다.
- TDD의 목표는 작동하는 깔끔한 코드 “Clean code that works”
- TDD는 아래 단계의 반복으로 진행된다.
빨강 : 실패하는 작은 테스트 케이스를 작성한다. 처음에는 컴파일조차 안될 수 있다.
초록 : 테스트를 통과하는 코드를 작성한다.
리펙터링 : 테스트를 통과하기 위해 만든 코드의 모든 중복을 제거하고, 불명확한 것을 명확히 한다.
이러한 단계로 인해 TDD는 “업무 코드 작성 전에 테스트 코드를 먼저 만드는 것”으로 정의되기도 한다
TDD 테스트 주도 개발이며, 하나의 개발 방법론 입니다.
- TDD는 반복 테스트을 이용한 소프트웨어 개발법이다. 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 소프트웨어를 구현한다.
- TDD의 목표는 작동하는 깔끔한 코드 “Clean code that works”
- TDD는 아래 단계의 반복으로 진행된다.
빨강 : 실패하는 작은 테스트 케이스를 작성한다. 처음에는 컴파일조차 안될 수 있다.
초록 : 테스트를 통과하는 코드를 작성한다.
리펙터링 : 테스트를 통과하기 위해 만든 코드의 모든 중복을 제거하고, 불명확한 것을 명확히 한다.
이러한 단계로 인해 TDD는 “업무 코드 작성 전에 테스트 코드를 먼저 만드는 것”으로 정의되기도 한다
개념 위주인 Basic 내용에 이어 '애완동물(spring-petclinic)' 어플리케이션 코드 대상으로 실제 테스트 코드를 작성하고 커버리지를 측정하는 교육입니다. 명세로부터 테스트를 도출하는 블랙박스 테스트 접근 이후, 코드 커버리지 정보로부터 추가 테스트를 작성하는 화이트박스 기법을 차례로 적용하고 있습니다
프로젝트가 진행될 수록 특정 테스트 만을 위한 설정 파일 수가 엄청 증가합니다. 그런데 설정파일은 변경될 수 밖에 없고, 카피해 두었던 테스트를 위한 설정파일들은 그 표준과 달라서 기존 테스트들을 깨지게 합니다.
설정 오버라이딩 이라는 개념을 도입하여 깔끔히 처리하는 방법을 소개합니다.
개념 위주인 Basic 내용에 이어 '애완동물(spring-petclinic)' 어플리케이션 코드 대상으로 실제 테스트 코드를 작성하고 커버리지를 측정하는 교육입니다. 명세로부터 테스트를 도출하는 블랙박스 테스트 접근 이후, 코드 커버리지 정보로부터 추가 테스트를 작성하는 화이트박스 기법을 차례로 적용하고 있습니다
프로젝트가 진행될 수록 특정 테스트 만을 위한 설정 파일 수가 엄청 증가합니다. 그런데 설정파일은 변경될 수 밖에 없고, 카피해 두었던 테스트를 위한 설정파일들은 그 표준과 달라서 기존 테스트들을 깨지게 합니다.
설정 오버라이딩 이라는 개념을 도입하여 깔끔히 처리하는 방법을 소개합니다.
예전에 인턴하면서 프로젝트해서 만든 자료인데 공유하고 싶어서 올립니다.
한국어로된 자료가 별로 없더라구요.
많은 레퍼런스 보고 만든 문서인데 혹시 필요하신분 있으면 참고하세요.
물론 이건 표준이고 현실에서는 표준을 따르지 않을 때도 많습니다.
프로젝트마다 테스트 강도를 조절하는 것이 좋다고 생각합니다.
Effective Unit Testing (케일)
- remarkjs로 작성후 브라우저로 pdf 인쇄
기본적으로 Effective Unit Testing을 바탕으로 내용을 만들었고, 좀더 공유하고 싶은 내용에 살을 붙였음.
예제 코드는 책에 없는건 직접 만들어 봤으나 의미가 잘 전달되지 않을수는 있다고 생각함.
깨끗한 테스트 원칙은 '클린코드' 책에 나오는 내용임.
상업적 이용 및 출처없는 무단전재를 금합니다.
애자일과 애자일 테스트 소개 (테스트기본교육 3장 2절)
애자일의 스크럼, XP에 대한 기본적인 소개와 스크럼 팀 안에서 테스트 역할자로써 사용자 스토리 리뷰, 테스트 설계, 짝 테스트, 테스트 자동화 등에 대한 내용을 사례 기반으로 소개하고 있습니다.
2. Goal 찾기 쉽고 이해하기 쉬운 테스트 조직하는 법 테스트 메소드 내부 구성 테스트 케이스 클래스 구성 테스트 스위트 구성
3. 테스트 스위트 테스트케이스 클래스 테스트 메소드 기본 xUnit메커니즘 테스팅 자동화 도구 사용시 작업 순서 테스트 찾기(521) 테스트 나열(528) 테스트 스위트 객체 생성(513) 테스트 실행기 (502)로 스위트 객체 메소드 실행 테스트 실행기 테스트 코드
4. 적당한 크기의 테스트 메소드 테스트 조건 = { SUT의 시작 상태, 실행 방법, 기대 응답, 종료 상태 } 테스트 메소드= 여러 테스트 코드를 실행
5. 바람직한 테스트 메소드 순차문, 한번에 하나만, SUT격리 순차문 한번에 하나의 조건만 검증 SUT격리
6. 테스트 메소드 조직 전략(1/4) 현실 문제는 두 부분의 사이 어디쯤에 있다. 하나의 테스트 케이스 클래스에 모든 테스트 메소드 하나의 테스트 케이스 클래스에 오직 하나의 테스트 메소드 VS
7. 테스트 메소드 조직 전략(2/4) 클래스별 테스트케이스 클래스 Testcase Class per Class(497) 테스트 메소드가 늘어나면, 테스트 케이스 클래스로 쪼갠다. Refectoring – Extract class와 유사
8. 테스트 메소드 조직 전략(3/4) 기능별 테스트케이스 클래스 기능 중심으로 테스트 케이스 구성 픽스처setup코드 중복 가능성 있음
9. 테스트 메소드 조직 전략(4/4) 픽스처별 테스트케이스 클래스 같은 선조건을 갖는 집합들이 하나의 클래스 테스트조건들이 흩어질 수 있다.
10. 상황에 따른 테스트 메소드 조직 전략 작업의 시작 하나의 테스트 케이스 클래스에서 시작 후, 테스트 코드 리팩토링 상태가 다양한 객체 픽스처별 테스트케이스 클래스 서비스 퍼사드, 고객 테스트 기능별 테스트 케이스 클래스 미리 만든 픽스처(562), 위임설치(541)로픽스처 설치
11. 테스트 이름 정하기 조합형 이름 테스트 패키지 테스트 케이스 클래스 테스트 메소드 이름 어떤것을 알 수 있나? SUT클래스 이름 실행하려는 메소드나 기능 이름 SUT나 그 SUT의존 객체의 상태 관련된것 그 테스트 케이스에 거는 기대 Should throw something…
12. 테스트 스위트 조직하기(1/4) 특정 부분에 관심이 있는 테스트 집단 이름 있는 테스트 스위트 부분 스위트 모든 테스트 스위트들은AllTests에서 실행 가능함.
13. 테스트 스위트 조직하기(2/4) 부분 스위트( xUnit에서는 Test selection 사용) 고객 테스트용 단위 테스트용 부분 스위트의 예 DB에 (종속 / 독립)적인 테스트 스위트 웹서버에(종속 / 독립)적인 테스트 스위트
14. 테스트 스위트 조직하기(3/4) 하나의 테스트 실행하기( 상황) 테스트 메소드 하나 실패 모든 테스트에서 실패한 메소드 호출 Break point를 넣고 싶은데…
15. 테스트 스위트 조직하기(4/4) 하나의 테스트 실행하기( 해결책 ) 중단점 호출 될 때까지 Go 원하는 테스트 말고 다른 테스트 이름 다 바꾸기 Test selection ( xUnit ) 최후의 보루, 하나의 테스트만 실행하는 테스트 스위트 작성
16. 테스트 코드 재사용(1/3) 올바른 테스트 코드 재사용 암묵적 설치, 테스트 유틸리티 메소드(760) 테스트 대역(670) – 여러 테스트에서 재사용, 테스트 주체가 아닌 테스트를 도와주는 Helper개념 여러 fixture에서 테스트 메소드 재사용
17. 테스트 코드 재사용(2/3) 테스트 유틸리티 메소드 위치 SUT의 객체 타입에 독립적인 여러 Test case에서 사용 도메인 패키지별Test Helper생성
18. 테스트 코드 재사용(3/3) 테스트 케이스 상속과 재사용 부모 클래스의 테스트 유틸리티 메소드를 사용하기 위한 상속 프레임워크와 프레임워크 플러그인 테스트를 위한 상속
19. 테스트 파일 구성(1/3) 내장 자체 테스트 제품 코드 안에 테스트 코드 포함 불필요한 메모리 공간 소비
20. 테스트 파일 구성(2/3) 테스트 패키지를 제품 패키지와 따로 두는 경우 같은 소스 폴더 + 테스트 패키지 형제 소스 트리 + 같은 패키지 빌드 타임에 테스트 코드를 컴파일 하지 않도록 해야 함.
21. 테스트 파일 구성(3/3) 테스트 의존 제품코드에 테스트를 위한 코드 기계적으로 제거 불가능함 사람이 코드를 확인하면서 지워줘야 함
22. 정리 언제나 통하는 정답은 없다 가이드라인 테스트 메소드: 한번에 하나의 테스트 코드 작성, 순차적인 코드 작성 테스트 케이스 클래스 : 테스트 메소드가 많아지면 클래스로 분리 테스트 이름은 의도가 드러나도록 명확히 작성 테스트 스위트: 목적에 맞게 여러 스위트로 나누어서 작성 테스트 코드 재사용 : 코드 중복 유지보수 비용증가, 테스트 유틸리티 클래스 적극 활용 테스트 파일 구성 : 가급적이면 제품코드에 테스트코드가 들어가지 않도록 배포