TDD (Test Driven Development)란?

https://festa.io/events/3791

한빛N MSA - #2 TDD | Festa!

주니어 개발자를 위한 TPO for TDD

"경험을 압축한 알고리즘 만한 것이 없다." - 정보람 강사님 

 

TDD 개발 방법론의 진화

• 구조적 기법 (1970 복잡성 극복)
  • monologic
• 정보공학 기법 (1980 자동화)
• 객체지향 기법 (1990 모듈화)
  • 사용자 관점의 서비스 설계
• CBD 기법 (2000 재사용)
  • component 개발, 재사성 증가
• Agile 기법 (2010 적시성)
  • TDD 방법론 **
  • MSA (micro service architecture)

일반적인 개발 방식

• 계획 - 계획서
• 요구분석 - 요구 분석
• (TDD) 설계 - 설계서
• (TDD) 구현 - 원시코드
• (TDD) 테스트 - 실행 테스트 보고서
• 운영 유지보수

TDD (Test Driven Development)

• 구현 설계 - > 개선 실패하는 테스트 추가 -> 테스트 통과 -> 구현 설계 ...
  RED : 해당 기능이 정상적으로 동작하는 지 검증
  GREEN : 테스트를 통과하는 데 성공하는 단계
  REFACTOR : 개발자는 변수 이름을 변경하고 구현을 요약하고 알고리즘을 변경

Example (빠른 코드 작성을 목표로 작성)

• 볼링 게임 예시
  1. 볼링 게임이 있다는 틀 작성 (최소한의 class 만 명시) - 게임 안에 "볼링"이라는 구현체 작성 - 테스트 통과!
  2. "볼링" 안에 공을 굴리는 함수 구현 - 테스트 통과!
  3. 리팩 토링 단계 공을 굴리는 작업과 game 선언 기능이 중복으로 작동할 경우 game = Game 제거 수정 setUp()
  4. 실패하는 테스트 추과 테스트 통과 여부 / 0 점이되는 "gutter game" 테스트 추가
     1. return 값이 0이되는 것을 작성 - 테스트 통과!
  5. 다시 refactoring 수행
  6. gutter_game refactoring ~
     1. Extract Method

TDD의 특징

TDD의 장점

• 코드 품질 향상
  • 반복적인 테스트가 쉬워지므로 유지 관리 가능한 코드 작성
  • 확장 용이, 고품질의 코드 생산
• 빠른 개발
  • 장기적으로 코드가 복잡해 질수록 좋음
  • 고도화와 동시에 테스트가 이루어져서 초기에 수정 작업이 가능
• 협업에 용이
  • 개발 단계에서도 요구 사항에 대한 테스트 코드가 존재

• Stub
  • 테스트 중인 클래스에 데이터를 제공 상태 확인에 사용
  • 테스트에 실패할 수 없음
• Mock
  • 테스트 중인 클래스에 의해 호출 동작 확인에 사용
  • 테스트에 실패할 수 있음
  • 데이터 + 구현을 제공
  •  
    
    • atomic stomic Fack

 

TDD의 단점

• 초기 투자시간
  • 테스트를 작성하기 위한 초기 투자시간이 필요함
• **테스트 코드를 작성하기 어려움
  • 특정 요구 사항의 경우 테스트 코드를 작성하기 어려움 ( 외부라이브러리 사용시, 의종성이 많은 경우)
• 느린 개발
  • 1번 작성할 코드를 여러번에 나눠 사용

 

TDD는 항상 옳지 않다

TDD에 관한 편견 바로 잡기

• TDD 무조선 해야 하나요?
  • 예상 일정과 자원을 고려해서 결정 필요
  • 초기 비용은 덤 많이 들 수 있으나 전체적으로 비용이 점진적으로 늘어나지 않다.
• TDD는 버그를 박멸해주나요?
  • 버그는 빠르고 효과적으로 개선할 수 있도록 프로그래머를 도와줄 수 있으나, 한계 존재
• TDD 도입시 업무 속도가 느려지나요?
  • TDD를 사용하기 위해 필요한 초기 자원이 미진해서 속도가 나지 않는다고 느껴지는 거다.
  • TDD자체가 목적이 되어서는 절대 않됨, 공동 목표를 효율적으로 달성하기 위한 도구 중에 하나이다.

 

BDD, DDD 맛보기

• BDD (Behavior Driven Development)
  • 
  • TDD를 근간으로 파생된 개발
  • TDD가 테스트 자체에 집중하는 반면, 비즈니스 요구사항에 집중하여 테스트 케이스 개발
  • TDD와 결합해 시나리오 구성
  • 테스트 케이스 자체가 요구사항이 되도록 개발하는 방식
• DDD (Domain Driven Development)
  • 
  • 도메인 주도 개발
  • 순수한 도메인의 모델과 로직에 집중
  • 분석 작업과 설계, 구현까지 통일된 방식
  • 도메인 모델부터 코드까지 향상
  • 함께 움직이는 구조의 모델을 지향

 

왜 실패 하는가?

사장님 : "우리도 애자일 그거 해야되지 않을까?"

• 애자일을 적용할 때 가장 중요한 것은 진행될 프로젝트와 개발 구성원 비즈니스 이해 관계자에 따라서
• 애자일을 유연하게 적용하는 것이다.
• 애자일이 정답이 아니기 때문에 조직과 어울리는 프로세스를 개발

 

성공 사례 - 레거시 프로젝트

 

예시 1 

• 단위 테스트 없이 몇년 전에 작성된 함수를 사용하는 새 기능을 개발
• 이전 코드에 대한 단위 테스트 작성 전까지 배포 할 수 없음

 

Solution )

• 레거시 코드를 블랙 박스로 취급
• 기존 코드에 대한 유닛 테스트를 작성
• 기존 코드에 대한 그린 상태를 유지하면서 리팩토링
• 이 후 새 기능을 TDD 기반으로 쌓아 올림

예시 2

• 웹 드라이브에 파일을 올리는 기능을 개발
• 업로드 되는 파일의 포맷이 다양함으로써 다양한 업로드 방법이 필요

Solution )

• 모든 코드는 컴포지션이다!
• 각 파일 타입 존재

예시 3

• 사용자가 급증하며 버그 발견 - 핫픽스를 제공

Solution )

• 변경 사항이 적용되고 고객 지원 통화량이 두배가 됨
• 핫 픽스가 기존의 코드를 깨뜨림
• 머피의 디버깅 법칙
• 단위 테스트 어설션을 재검포 - assert 검토
• 코드가 문서화된 대로 작동한다는 증거 == 테스트코드

결론

• 처음 해보는 프로그램 주제
• 고객이 요구 사항이 바뀔 수 있는 프로젝트
• 개발하는 중에 코드를 많이 바꿔야 된다고 생각하는 경우
• 내가 개발하고 이 코드를 누가 유지 보수 할 지 모르는 경우

 

테스트는 필수 커버리지는 비즈니스 중요도와 상황에 따라서!

 

QnA

데이터 분석 시 패키지 의존성이 높은데 TDD 유효 한지?
- 신기술 상황에 맞춰 사용

- 중요한 것은 테스트! 테스트는 필수이며 방법론은 상황에 맞춰 적용하라

 

 나의 경우 반복되는 EDA 과정을 TDD를 도입하면 처음 도입하기 위해 테스트 환경에 시간을 많이 잡아먹어 다른 데이터에서도 유효한 검증을 반복해야한다. 하지만 처음 구축해놓은 테스트 과정을 다른 데이터에서도 유효한 검정으로 mockup을 만든다면 시간도 절약하고 레거시를 남겨 공유가 가능한 코드로 확장할 수 있을 것으로 보인다. 

 

 TDD를 처음 접했을 때 오류 없는 개발 단계 과정으로 생각해 본 강의 선생님과 같이 이거 만능이구나 싶어 기초적인 기능만 사용하고 있는데 개발 직군에서는 전혀 사용하지 않는 방법론이라 해서 우물안의 개구리가 이렇게 무지하구 느꼈다.