주니어 개발자를 위한 TPO for TDD 세미나 후기

개요

TPO for TDD 세미나를 듣고와서 내용을 정리하고, 느낀점을 포스팅해봤습니다.

여기서 TPO란 Time(시간), Place(장소), Occasion(상황)에 따른 TDD 적용 이라는 의미 같습니다.

전체적인 맥락에서 강사님이 말씀하시는 TDD 가 유연하게 필요에 따라 적용되어야 한다는 점과

특히 강조하시는 테스트의 중요성에 대해서 인상깊게 들었습니다.

 

 

 

개발 방법론의 진화

테스트 주도 개발(이하 TDD)이라는 방법론이 나오기 이전에 개발 방법론은 필요에 따라 진화해 왔다고 한다.

대략적인 진화도를 보자면, 구조적 → 정보공학 → 객체지향 → CBD → Agile

방법론과 더불어 프로그램을 다룰 수 있는 운영체제와 환경도 진화해 왔다.

단일 OS → 하이퍼바이저(가상 OS) → 컨테이너 → 오케스트레이션

그리고 아키텍처또한 기본적인 모놀로식 → 마이크로 서비스 아키텍처

 

 

일반 개발 방식

일반적으로 개발을 하는 방식은 폭포수 방식처럼

계획 → 요구분석 → [설계 → 구현 → 테스트] → 운영,유지보수

이루어 지는데, TDD는 [설계 → 구현 → 테스트] 범위의 애플리케이션 실제 개발단계에서의 방법론이다.

 

 

TDD (Test Driven Development) 란?

• RED(write a failing test) : 해당 기능이 정상적으로 동작하는지 검증하기 위한 테스트 작성
• GREEN(make the test pass) : 테스트를 통과하는 최소한의 코드 작성
• BLUE(refactor) : 테스트에 성공한 코드를 리팩토링

 

 

예제 1. 볼링게임

1. 볼링 게임은 1개의 프레임
2. 각프레임은 2롤을 가짐
3. spare : 10 + 다음 첫번째 롤에서 쓰러뜨린 핀
4. stike : 10 + 다음 두 롤에서 쓰러드린 수

---

1. 클래스를 만들어 아무 동작도 하지 않는 코드 및 실패하는 코드 작성 →
   1. 0점으로 테스트를 실패하는 (거터게임)테스트 작성
   2. 테스트를 실패함으로써 기본 토대를 만듬
2. 테스트를 통과하는 최소한의 코드만 만듬 →
   1. 전부 1점일 때 통과하는 경우를 만듬
3. 구현 설계 개선 →
   1. 테스트에 있는 중복 제거
   2. 공통 함수를 생성해서 호출을 공통 함수에서 하도록 개선
   3. …개선 작업

사이클 반복

 

 

 

TDD 특징 : 장,단점

TDD 특징과 장점

1. 코드 품질 향상황장이 용이 (변경 시 Side-effect 발견이 쉬움) 고품질의 코드 생산
2. 반복적인 테스트가 쉬워지므로 유지 관리 가능한 코드를 작성할 수 있음
3. 빠른 개발고도화와 동시에 테스트가 이뤄져서 초기에 수정 작업이 가능
4. 장기적으로 코드가 복잡해 질수록
5. 협업에 용이
6. 개발 단계에서도 요구 사항에 대한 테스트 코드가 존재

TDD 단점

1. 초기 투자 시간
2. 테스트를 작성하기 위한 초기 투자 시간이 필요함
3. 테스트 코드를 작성하기 어려움
4. 특정 요구 사항의 경우 테스트 코드를 작성하기 어려움
5. 느린 개발실패 테스트 작성 → 테스트 → 성공 테스트 작성 → 테스트 … 생산성 낮아짐
6. 1번 작성할 코드를 여러번에 나눠 작성하게 됨

 

 

테스트 코드 작성 시 사용할 수 있는 객체 의존성 - 테스트 더블(Test Doubles)

Stub

• 테스트 중인 클래스에 데이터를 제공
• 상태 확인에 사용
• 테스트에 실패할 수 없음

Mock

• 테스트 중인 클래스에 의해 호출
• 동작 확인에 사용
• 테스트에 실패할 수 있음
• 데이터 + 구현을 제공

… 외에도 Fakes, spy 등이 있음

 

 

TDD 에 관한 편견

• TDD는 무조건 해야하는게 아님, 초기 비용이 많으 들지만 전체적으로 비용이 점진적으로 낮아짐
• TDD가 버그를 없애지는 않음, 버그를 효과적으로 개선할 수 있도록 할 수 있으나 버그 자체가 없어지진 않음
• TDD를 도입하면 업무속도가 느려지진 않음, 초기 자원이 미진할 땐 속도가 나지 않는다고 느끼지만, 익숙해지면 점진적으로 빨라짐
• TDD자체가 목적이 되면 안됨, 공동의 목표를 효율적으로 달성하기 위한 도구일뿐

방법론이나 기술의 선택의 폭을 넓히기 위함, 기술 자체가 목표가 아님

 

 

BDD

Behavior Driven Development

• TDD를 근간으로 파생된 개발 프로세스
• TDD가 테스트 자체에 집중된 반면
• BDD는 비즈니스 요구사항에 집중하여 테스트 케이스 개발
• 테스트 케이스 자체가 요구 사양이 되도록 개발하는 방식
• TDD와 결합해 시나리오 테스트까지

 

DDD

Domain Driven development

• 도메인 주도 개발
• 순수한 도메인의 모델과 로직에 집중
• 분석 작업과 설계, 구현까지 통일된 방식
• 도메인 모델부터 코드까지
• 함께 움직이는 구조의 모델을 지향

 

 

성공 사례 - 레거시

• 단위 테스트 없이 예전에 작성된 함수를 사용하는 새 기능 개발
• 이전 코드에 대한 단위 테스트 작성 전까지 배포할 수 없음
• 레거시 코드를 블랙박스로 취급
• 모든 코드는 컴포지션이다?
• 기존 코드에 대한 유닛 테스트를 작성
• 기존 코드에 대한 그린 상태를 유지하면서 리팩토링
• 의존성 테스트에는 최대한 Mock 을 사용

---

• 사용자가 급증하며 보그가 발견되어 핫픽스를 제공
• 변경 사항이 적용되고 고객 지원 통화량이 두배가 됨
• 핫픽스가 기존의 코드를 깨뜨림
• 머피의 디버깅 법칙?
• 단위 테스트 어설션(asertion)을 재검토
• 코드가 문서화된 대로 작당한다는 증거 == 테스트 코드

 

TDD를 적용하기 좋은 경우

1. 처음 해보는 프로그램 주제
2. 고객의 요구 사항이 바뀔 수 있는 프로젝트 (외부적인 불확실성이 높음)
3. 개발하는 중에 코드를 많이 바꿔야한다고 생각하는 경우
4. 내가 개발하고 이 코드를 누가 유지보수 할 지 모르는 경우

 

 

결론

테스트는 필수로 진행해야 하지만, TDD가 무조건 먼저 적용되어야 하는건 아님

커버리지 또한 너무 집착하지 않고 비즈니스의 따라, 필요에 따라 사용되어야 함

적절한 커버리지는 60~80 % 라고 하지만, 실제 현업에서는 지켜지기 힘듬

---

 

 

 

 

느낀점

강사님께서 재밌게 말을 풀어서 해주시려고 준비하고 노력하신게 보인 세미나였다. TDD가 어떤건지, 어떤 방식으로 진행되는지에 대해 다시 생각해 볼 수 있었고, 예제와 성공사례로 TDD가 비즈니스에 따라 어떻게 적용해야 할지와 무조건 장점만 있는 개발방법론이 아니란점에 대해 다시 생각해볼 수 있었다. 그리고 현업에서 실제로 사용하기 어렵고, 실패하는 이유에 대해 설명하셨을 때는 어느정도 이해는 되었다. TDD를 하면서 비즈니스 코드보다 테스트 코드를 중요시하면 안된다는 점과 커버리지에 집착하지 않고 유연하게 필요에 따라 적용해야 한다고 하셨으며, BDD, DDD등의 다른 개발 방법론도 함께 알아보면 좋겠다고 한다.