테스트 주도 개발 - TDD란?

  안녕하세요. 이번 시간엔 테스트 주도 개발이라 불리는 TDD - Test Driven Development 에 대해서 다뤄보려고 합니다. 최근 많은 기업들이 TDD와 DDD 기반의 개발, 테스트 문화를 채택하고 있어 현재 개발 시장에서 트랜드라고 해도 무방하지만.. 제가 SI업무를 하다보니 실무에서 접할 기회가 없어 이렇게 따로 학습하여 정리해보고자 합니다. 부족한 점이 많으니, 교정은 언제든 환영입니다!

  테스트 주도 개발(TDD) 는 크게 두 가지 범주로 나눌 수 있습니다.

---

• TDD(Test Driven Development) : 순수한 자바 기반의 테스트 코드를 작성하는 것

 

• ATDD(Application Test Driven Development) : Spring과 같은 프레임워크와 결합된 어플리케이션을 계층 단위 (MVC 패턴을 사용한다면, Controller Service Repository로 나누어 테스트 케이스를 작성하는 형태)로 나누어 테스트를 진행

---

위와 같이 범주를 두 가지로 나누어놓으니 완전히 별개처럼 느껴지지만, 큰 틀에선 두 가지 모두 TDD라고 보시면 될 것 같습니다. 다만, 테스트 주도 개발을 Spring과 같은 프레임워크에 적용한다면 미시적인 관점에서 ATDD로 해석하는 것 같습니다.

 

※ 왜 TDD인가?

  포스팅을 하기 위해 TDD관련 글들을 많이 읽어보고, 자바를 비롯해 Spring의 계층별 테스트 케이스도 Mockito 라이브러리를 활용해 모두 작성해보았지만 크게 그 실용성이나 장점을 느끼기 어려웠습니다. 업무에 적용하거나 실제 프로젝트를 하며 사용한 것이 아니고 단순히 학습을 위한 간단한 테스트 케이스만 작성해서 그런 것인지는 모르겠으나, 여러 글에서 장점으로 언급하는 중복코드 제거, 장기적 관점에서의 개발비용 절감 등의 장점을 단시간에 깨닫기란 힘든 일인 것 같습니다.

 

일반적으로 테스트 주도 개발의 장점 및 사용하는 이유에 대해서는 다음과 같이 정리할 수 있을 것 같습니다.

---

• 소스 코드의 안정성 확보 
• 반복적인 리팩토링을 통해 Clean-Code 지향
• 개발 비용 절감

---

기본적으로 TDD는 RED BLUE GREEN 의 과정을 순환하며 특정 기능을 수행하는 코드를 리팩토링 합니다.

RED 단계에서는 실패하는 테스트 코드를 추가하고 

BLUE 단계에서는 성공하는 테스트 코드를 추가하며

GREEN 단계에서 중복코드를 제거하는 등의 리팩토링을 진행합니다.

즉, TDD를 진행한다는 것은 하나의 기능을 수행하는 메서드에 대해서 실패케이스와 성공케이스 작성을 반복해나가며 중복을 제거하고 리팩토링함으로써 깔끔한 코드를 만들어 나간다는 의미를 지니고 있습니다. 그리고, 이렇게 작성된 테스트 코드는 추후 프로덕션 코드를 작성할 때 설계적인 측면에서 참조가 가능하고, 또 특정 기능에 문제가 생겼을 때 테스트 케이스를 활용함으로써 문제를 빠르게 파악할 수 있다는 점에서 장기적으로 봤을 때 개발비용을 절감해준다는 장점을 가집니다.

Clean Code의 저자 로버트 마틴은 해당 저서에서 TDD의 핵심 규칙을 FIRST로 요약하여 설명하고 있습니다.

---

1. FAST : 단위 테스트는 빠르게 동작하여야 한다.
2. Independent : 각각의 테스트는 독립적이며 서로 의존해서는 안 된다. 즉 그 자체만으로 실행되어야 한다.
3. Repeatable : 환경에 구애받지 않고 반복 가능해야 한다. (멱등성)
4. Self-Validating : 단위 테스트는 자체적으로 검증 가능해야 한다. (성공 또는 실패)
5. Timely : 단위 테스트는 프로덕션 코드를 구현하기 직전에 작성한다.

---

 

※ 문제점

  문제점 중 가장 직관적으로 다가오는 것은 바로 개발 시간 증가에 따른 생산성 저하인 것 같습니다. SI업무의 경우 정해진 기간 안에 개발을 완료해야 하는 상황에서 테스트 코드를 작성한 후 프로덕션 코드를 작성하게 되면 개발 기한을 지키기 어려운 경우가 생길 수 있을 것 같습니다. 이러한 상황을 고려하지 않고 무작정 TDD를 도입하게 되면 개발 일정에 쫓겨 형식적인 테스트 코드를 작성하거나 이미 작성되어 있는 코드를 가져와 일부분만 수정하여 반영하는 등의 문제가 생기게 될 것입니다. 

 

남들이 한다고해서, 혹은 트랜드니까 무작정 도입하는 것이 아니라 테스트 주도 개발이 가져다 주는 이점과 그것을 행하는 의미를 잘 기억하며 적용해 나가는 것이 중요할 것 같습니다. 다음 포스팅에서는 TDD를 직접 코드로 작성해보며 정리하는 시간을 가져보도록 하겠습니다.

 

※ Reference

https://mangkyu.tistory.com/143

[TDD] 단위 테스트(Unit Test) 작성의 필요성 (1/3)

https://mangkyu.tistory.com/182

[TDD] 단위 테스트와 TDD(테스트 주도 개발) 프로그래밍 방법 소개 - (1/5)

https://velog.io/@wngud4950/TDD%EB%9E%80

TDD, 테스트 주도 개발이란?

https://gmlwjd9405.github.io/2018/06/03/agile-tdd.html

[Agile] TDD(테스트 주도 개발)란 - Heee's Development Blog

https://fomaios.tistory.com/entry/CS-FIRST-%EC%9B%90%EC%B9%99%EC%9D%B4%EB%9E%80-featUnitTest

[CS] F.I.R.S.T 원칙이란? (feat.UnitTest)