TDD (Test-driven development)
테스트 중심 개발(TDD, Test-driven development)
정의 : 테스트 중심 개발은 코딩, 테스트(단위 테스트 형식), 설계(리팩터링 형식)의 세 가지 활동이 밀접하게 연계되는 프로그래밍 스타일이다.
효과적인 이유 : TDD는 더 고품질의 프로그래밍을 실현한다. TDD를 사용하면 테스트를 충족하기에 충분한 코드만 작성하게 된다. 그 결과 테스트를 거쳤을 뿐만 아니라 확장성과 유지보수 편의성도 높은, 더 모듈성이 강하고 군더더기 없는 코드가 생산된다. TDD는 또한 총소유비용(TCO) 절감으로도 이어진다. 결함의 수가 더 적다. 결함 수정 비용이 덜 드는 사이클의 조기에 결함을 포착할 수 있다.
효과를 거두지 못하는 경우 : TDD는 숙련되기까지 4~6개월이 소요된다. 이 램프업 기간 동안 TDD는 팀의 속도를 떨어트린다. 또한 선행 투자도 더 많이 필요하다. 그러나 장기적인 비용이 절감되므로 이 비용은 결국 상쇄된다.
(http://www.itworld.co.kr/news/109011
"BDD부터 TDD까지" 다양한 애자일 기법의 장단점 - ITWorld Korea
외부에서 보면 애자일은 한 가지 방식으로 보인다. 그러나 안으로 들어와서 보면 애자일 실천가들은 각자 다양한 방식에 전념해 작업을 한다. 어떻게 하면 나와 내 팀에 잘 맞는 기법을 찾을 수
www.itworld.co.kr
[참고]Martin Fowler, Workflows of Refactoring
Workflows of Refactoring
Many teams miss opportunities for refactoring by not realizing the different ways refactoring can fit into their workflows.
martinfowler.com
함수 시그니처 고려
- 어떤 입력과 출력(동작)이 함수 호출에 필요한가?
- 코드에서 함수를 어떻게 호출할 것인지 결정하기
- 생각하는 입력에 대한 동작의 가장 작은 부분 선택하기
- 입력값으로 함수를 호출하는 테스트 코드를 작성하고, 동작을 검증하기
- 테스트를 충분히 통과하는 코드를 구현
[번역]쉬운 테스트 주도 개발과 단위 테스트를 위한 5단계 방법론
이 글은 Jani Hartikainen의 5 step method to make test-driven development and unit testing easy를 번역한 글입니다.
medium.com
1. TDD : (개별단위,모듈단위)(하위레벨) : Test Case를 먼저 개발하고 Test Case를 통과하는 Code를 나중에 개발하는 Agile 개발방법
[특징] 단위테스트부터 설계
- 프로그램에 대한 테스트 설계를 먼저하고 이 테스트를 통과할 수 있도록
실제 프로그램의 코드를 반복적인 리팩토링 과정으로 완성해 가는 개발 방법론
- simple code , Iteration , 품질향상
2. TDD 구성요소
1) 사용자 요구사항 : 사용자, BA, 제품 개발자 등이 요구사항 Story 작성
2) Test Case 사용자 : Tester 등 관련자들이 Test Case를 마련 Detail하게 작성
3) Code 작성 : 테스트에 대해 실행 가능한 코드를 빠르게 작성(임시코드/자료삽입, 가짜 구현, 명백한 구현)
4) Refactoring : Bad small을 제거하여 Refactoring 수행 후 Simple code에 대한 Test 수행
3. TDD에서 사용하는 패턴(아래그림내용암기)
Red | 모든 새로운 기능의 개발은 실패한 테스트로 시작 (실제로 배포할 기능을 구현하는 코드가 아니기 때문) 테스트를 통과할 수 있는 최소한의 코드를 작성하여 테스트를 다시 실행 |
Green | 테스트 성공 상태 |
Refactor | 코드를 정리하고, 중복 코드를 제거하며, 유지보수가 용이하도록 코드를 단순화하는 과정 |
패턴 | 설명 |
빨간막대 패턴 | -테스트 작성 후 실행되지 않는 기 개발된 모듈 내부에 대한 검증 - 실패하는 작은 테스트를 작성. |
초록막대 패턴 | -코드가 테스트를 통과하도록 신속하게 작동하는 코드 작성 -빨리 테스트가 작동하여, 통과하도록 함. |
테스팅 패턴 | - 테스트-모듈 간 적합성/성능, 견고함 검증 |
xUnit 패턴 | - xUnit 계열 테스트 프레임워크를 활용하기 위한 방법 제시 |
디자인 패턴 | - 유사 도메인에서 발생하는 문제 해결 위한 Best Practice 모음 |
3. TDD 수행원칙
- 테스트마다 한 가지씩만 검증
- 중복되는 코드 제거 (Bad Smell)
- 소스의 의존성 최소화
- Automatic: 테스트가 혼자 실행, 자신을 검증할 수 있어야 함
- Through: 철저함, 문제 영역에 대한 완벽한 테스트 지원
- Repeatable: 반복가능, 같은 결과 도출
- Independent: 하나의 대상에 집중, 독립적 상태 유지, 다른 테스트 의존 안 함
- Professional(전문적): 캡슐화, 낮은결합도의 원칙이 테스트코드에서도 지켜야함
회사에서 TDD 쓰려다 실패한 후기
켄트 백의 전설적인 저서 'TDD by example'이 출시된 지 20년이 지났지만, 실무에서 적용하는 회사는 많지 않습니다. 회사에서 TDD를 시도했다가 실패한 후기를 공유합니다.
velog.io
'02.SW' 카테고리의 다른 글
SW 테스트 - 정적 테스트 - SW Review (0) | 2020.06.23 |
---|---|
SW 개발 방법론 - 애자일 - 분산 애자일(Distributed agile) (0) | 2020.06.19 |
SW 개발 방법론 - 애자일 - XP (0) | 2020.06.19 |
SW 개발 방법론 - 애자일 - 스크럼 (Scrum) (0) | 2020.06.19 |
SW 품질 - TMM (0) | 2020.06.19 |