728x90
반응형

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

 

함수 시그니처 고려

 

  1. 어떤 입력과 출력(동작)이 함수 호출에 필요한가?
  2. 코드에서 함수를 어떻게 호출할 것인지 결정하기
  3. 생각하는 입력에 대한 동작의 가장 작은 부분 선택하기
  4. 입력값으로 함수를 호출하는 테스트 코드를 작성하고, 동작을 검증하기
  5. 테스트를 충분히 통과하는 코드를 구현

 

(https://medium.com/@cmygray/%EB%B2%88%EC%97%AD-%EC%89%AC%EC%9A%B4-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%A3%BC%EB%8F%84-%EA%B0%9C%EB%B0%9C%EA%B3%BC-%EB%8B%A8%EC%9C%84-%ED%85%8C%EC%8A%A4%ED%8A%B8%EB%A5%BC-%EC%9C%84%ED%95%9C-5%EB%8B%A8%EA%B3%84-%EB%B0%A9%EB%B2%95%EB%A1%A0-b82fea6c8d90

 

[번역]쉬운 테스트 주도 개발과 단위 테스트를 위한 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(전문적): 캡슐화, 낮은결합도의 원칙이 테스트코드에서도 지켜야함

 

https://velog.io/@skynet/%ED%9A%8C%EC%82%AC%EC%97%90%EC%84%9C-TDD-%EC%93%B0%EB%A0%A4%EB%8B%A4-%EC%8B%A4%ED%8C%A8%ED%95%9C-%ED%9B%84%EA%B8%B0

 

회사에서 TDD 쓰려다 실패한 후기

켄트 백의 전설적인 저서 'TDD by example'이 출시된 지 20년이 지났지만, 실무에서 적용하는 회사는 많지 않습니다. 회사에서 TDD를 시도했다가 실패한 후기를 공유합니다.

velog.io

 

728x90
Posted by Mr. Slumber
,