TDD란

한 기업의 기술 면접에서 오답을 말했던 TDD의 개념을 재정립 하기 위해 그동안 본인이 Django를 통한 TDD를 진행하던 중 느꼈던 개념과, 문제 및 해결 과정을 작성해봅니다.

피드백은 언제나 환영입니다.

TDD란

Test Driven Development

테스트 주도 개발 : 테스트가 개발을 이끌어 나아간다.

TDD는 리팩토링이 빠질 수 없다. ( 테스트 패스를 하기 위한 코드의 수정이 일어나기 때문)

TDD의 개념

테스트를 먼저 만들고, 테스트를 통과하는 로직을 짜는 것

method를 만드는 과정에서 우선 테스트를 작성하고, 그것을 통과하는 코드를 만들고 리팩토링하며 제대로 동작하는 피드백을 적극적으로 반영하는 방법.

• 보통 SW 개발을 할 때 기능을 다 만들고 난 후, 테스트를 진행한다
  • 기능을 다 만들었다의 기준이 개발자이기 때문에 불분명하다.
  • 이런 기준을 바꾸는 것이 TDD이다.
  • 테스트를 통과하지 못한 method는 개방하지 않는다.
  • 모든 기능은 테스트케이스가 많을수록 좋은 테스트코드가 진행된다.
  • 테스트 케이스는 다른 백엔드 개발자들이 해당하는 method의 동작을 이해하는데 도움을 준다.(테스트코드 또한 좋은 문서가 될 수 있다. - 특정 method의 input value, repsonse data등을 알 수 도 있으며, 검증해야 하는 과정들이 결국 test_case의 함수 명이 될 것이라 명시적으로 다른 개발자들도 파악할 수 있기 때문)

추상적인 레벨에서의 TDD 핵심 개념

결정과 피드백 사이 갭에 대한 인식, 더 나아가 결정과 피드백 사이 갭을 조절하는 테크닉

켄트 벡이 말하는 TDD (중요!)

• 결정과 피드백 사이 간극을 의식하고 이를 제어하는 기술

• TDD는 테스트 기술이 아니라 TDD는 분석 기술이며, 설계 기술이다.

  결정 : 기능 구현 중 '어떤 방법으로 할 지', '어떤 개념을 사용해서 구현을 할 지'라는 것에 대한 결정

  피드백 : 기능 구현 중 얻게 되는 status code를 받는다. (성공과 실패)

  결정과 피드백사의 간극 을 의식하는 개발이 되야 한다.

TDD 의 핵심

• 큰 단위를 작은 단위로 나누어 지속적인 피드백을 통해 목표하고 개선한다.
• 달성하기 힘들 것으로 생각하는 일에 도전한다.

TDD의 장단점

• TDD를 하면 개발 시간이 늘어난다.

  • 개발 시간 : 기능의 구현이 완료 될 때
  • 개발 시간이 TDD를 하지 않았을 때에 비하여 10%~ 30% 늘어난다.

• TDD를 하면 결함이 줄어든다.

  • 결함이 1/ 2 ~ 1/ 10 까지 줄어든다.
  • SW를 개발하면서 예상하지 못했던 시간들이 많이 소요하게 되는 경우는 버그 떄문
  • TDD를 하면 이런 버그를 잡게 된다.

• TDD를 하면 코드 복잡도가 떨어진다.

  • 엔트로피(Entropie)가 낮아진다.
  • 클린 코드 작성.
  • 유지보수 비용이 감소한다.

TDD를 할 때 감안해야 하는 점

• 개발 시간의 증가
  • 단기적인 성과로는 의미가 없다.
  • 전체 개발 시간에 대한 여유가 없다면, 기한이 정해져 있는 프로젝트는 TDD에 대한 제약이 생긴다.
  • 단기적으로 한 만큼 장기적인 서비스로는 이후 많은 인적 비용을 지불해야 한다.(유지보수)
• TDD는 어렵다.
  • TDD를 해오지 않은 개발자들은 개발하던 방식을 바꾸어야 한다.

각 테스트의 종류

유닛 테스트( 단위 테스트)

• 가장 작은 단위 테스트
• 보통 메서드 레벨
• A 라는 함수가 실행되면 B 라는 결과가 나온다
• 즉각적인 피드백이 나온다는 장점
• 꼭 메모리 내에서만 실행 되는 테스트여야 한다는 법칙은 없다
  • DB, network, file 시스템등을 사용해도 단위테스트 레벨일 수 있다.
• 하나의 메서드들이 잘 동작한다는 것은 보장할 수 있지만, 그들이 결합되었을 때 잘 동작한다는것은 보장할 수 없다.
• 개발자 중심

전 구간 테스트 (End to End Test)

• 해당 시스템과, 해당 시스템을 구축하고 배포하는 프로세스 모두 시험하는 것
• 내부 기능까지(클래스 메서드까지) 테스트 할 필요는 없다.
• 테스트를 만들기가 힘들고, 만든 테스트를 신뢰하기도 힘들다.

통합 테스트 (Integration Test)

• 기본적으로 여러개를 통합해서 테스트 할 때 사용.
• 정확한 기준이 없다.
• 책에서는 변경할 수 없는 부분까지 묶어서 테스트할 때 사용한다고 한다.

여기까지의 테스트 방법들은 결함을 찾고, 요구사항의 조건에 충족하는지를 보는 것이 목적.

인수 테스트(Acceptance Test)

• 단위 테스트, 전 구간 테스트, 통합 테스트와는 Scope가 다르다.
• 구현하고자 하는 기능(비즈니스 레벨)에 대한 테스트이다.
• 대체적으로 전 구간 테스트를 사용하여 기능을 테스트한다.
• 하지만 결과적으론, 위 3가지 모두 인수테스트 범위에 들어갈 수 있다.
• 고객이나 실제 사용자가 참여한 개발된 시스템이 고객의 요구사항과 일치하는지 확인하는 고객 입장의 테스트

자료 출처

• 나는 왜 TDD에 집착하는가?
• Agile TDD란
• 단위 테스트 활용 방법