TDD ( Test- Driven - Development ) 에 대하여

TDD란 ?!

테스트 주도 개발 TDD는 설계 이후 코드 개발 및 테스트케이스를 작성하는 기존 개발 프로세스와 다르게 테스트케이스 작성 후 실제 코드를 개발하여 리펙트링 하는 절차를 말한다. ( = Test First Development )

짧은 개발 주기의 반복에 의존하는 개발 프로세스이며 애자일 방법론 중 하나인 eXtream Programming ( XP )의 test first 개념에 기반한 방법이다. 

 

 

TDD가 필요한 이유?

1. 깔끔한 코드를 작성할 수 있다. ( 중요! )

2. 장기적으로 개발 비용을 절감할 수 있다. 

3. 개발 후 테스트코드를 작성하는 것이 매우 힘들고 귀찮다. 

 

TDD 개발 단계에는 리팩토링이 있는데 이 과정을 통해 중복된 코드들은 제거되고 복잡한 코드들이 정리된다. 

프로덕션 코드를 먼저 작성한 후 테스트 코드를 작성하는 과정은 매우 번거롭고 귀찮은 작업이다. 

실패하는 경우를 우선 테스트 할 수 있도록 코드를 작성하는 것이 좋다. 

 

 

TDD 방법 및 순서

 

 

Red : 실패하는 테스트 코드를 먼저 작성한다. 

Green : 테스트 코드를 성공시키기 위한 실제 코드를 작성한다. 

Yellow : 중복 코드 제거, 일반화 등 리팩터링을 수행한다. 

 

 

[ 정리 ]

1. 실패하는 작은 단위 테스트를 작성한다. 

2. 빨리 테스트를 통과하기 위해 프로덕션 코드를 작성한다. 이를 위해 정답이 아닌 가짜 구현 등을 작성할 수 있다. 

3. 그 다음 테스트 코드를 작성한다. 실패 테스트가 없을 경우에만 성공 테스트를 작성한다. 

4. 새로운 테스트를 통과하기 위해 프로덕션 코드를 추가 & 수정한다. 

5. 1~4 단계를 반복하며 실패 / 성공의 모든 테스트 케이스를 작성한다. 

6. 개발된 코드들에 대해 모든 중복을 제거하며 리팩토링한다. 

 

 

TDD의  대표적인 Tool "JUnit"

- JUnit은 Java 단위 테스트 프레임워크로 에릭 감마와 켄트 벡이 탄생 시켰다. ( Spring 관련 글에서 자세히 다룰 예정 )

Junit 기반 테스트 코드 예시

 

TDD의 장단점

장점

1. 객체 지향적 코드 생산 

- 기능 별 철저한 모듈화가 이루어진다. 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하며 필요에 따라 모듈을 추가, 제거해도 소프트웨어 전체 구조에 영향을 미치지 않게 된다. 

 

2. 재설계 시간 단축

- 테스트코드가 우선 작성되면서 소프트웨어를 분명히 정의하고 개발을 시작하게 된다. 

 

3. 디버깅 시간 단축

- 자동화된 단위테스트를 전재하므로 특정 버그를 손쉽게 찾아낼 수 있다. 

 

4. 테스트 문서의 대체 기능

- 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있다. 

 

5. 코드 작성의 효율성 증가

- 리팩터링과 복잡한 로직 단순화를 통해 코드 효율을 높일 수 있다. 

 

 

단점 

1. 생산성 저하 발생 가능

- 개발 속도가 느려질 수 있는 문제가 있다. 단순 어플리케이션 개발의 경우 어떤 예외사항이 있는지 대부분 예상 가능한 경우가 많음. 이러한 단발성 개발은 개발 기간이 타이트한 경우가 많은데 테스트 코드 작성에 시간을 많이 부여하는 것은 비효율적

 

 

단위테스트  vs 통합 테스트

단위 테스트 

- 하나의 모듈, 기능을 기준으로 독립적으로 진행되는 가장 작은 단위의 테스트

- 하나의 기능 또는 메소드를 테스트하기 위함을 의미하며 어떤 기능이 실행되면 어떤 결과가 나돈다 정도로 테스트를 진행한다. 

- 단위테스트의 경우 독립적 테스트이기 때문에 다른 객체와 메세지를 주고 받아야하는 경우 문제가 발생한다. 이에 다른 객체 대신에 가짜 객체 Mock Object를 주입하여 어떤 결과를 반환하라고 정해진 답변을 준비한다. 이를 Stub 이라고 한다. 

 

Ex)  데이터베이스에 새 데이터 추가 코드를 테스트 한다고 하면, 가짜 데이터베이스 (Mock Database)를 주입하여 데이터 추가 시 반드시 1을 반환하도록 해주는 것이 Stub이다. 

 

통합 테스트

- 모듈을 통합하는 과정에서 모듈 간의 호환성을 확인하기 위해 수행되는 테스트를

- 여러개의 모듈로 구성된 소프트웨어에서 모듈들끼리 메세지를 주고 받으며 기능을 수행하는 절차를 테스트하는 것이다.

- 통합된 모듈들이 올바르게 연계되어 동작하는지 검증한다. 

 

 

좋은 단위 테스트란 ?

원칙!

1. 1개의 테스트 함수에 대해 assert를 최소화한다. 

2. 1개의 테스트 함수는 1가지 개념만을 테스트한다. 

 

FIRST 규칙

1. Fast : 빠르게 동작하여 자주 돌릴 수 있도록 해야한다. 

2. Independent : 각각의 테스트는 독립적이며 서로 의존해서는 안된다. 

3. Repeatable :어느 환경에서도 반복 가능해야한다. 

4. Self-Validating :테스트 성공 또는 실패로 bool값으로 결과를 내어 자체적으로 검증되어야 한다. 

5. Timely : 테스트는 적시에, 즉 테스트하려는 실제 코드를 구현하기 직전에 구현해야 한다. 

 

---

TDD에 도전해본 경험이 있으나,,쉽지 많은 않았다. 

내가 작성하고 있는 테스트 코드가 맞는 코드 인지, 테스트 경우의 수는 무엇이 있는지, 모듈 분리는 제대로 되고 있는지.. 확신할 수 없었다. 

또한 실패하는 경우의 테스트 케이스를 가정하고 우선 작업하는 것도 쉽지 않았고 개발을 위한 테스트가 제대로 진행되고 있는 건지 의문이 들때가 있었다. 😭

TDD가 쉽지는 않지만 그래도 꼭 필요하고 몸에 익숙해져야할 방법이라 생각하기에 개발에 있어 이 부분을 많이 고려해야 한다고 생각한다. 

많은 연습이 필요하고 더 좋은 방법과 코드는 무엇인지 고민할 줄 아는 개발자가 되어야겠다는 생각을 더욱 많이 하게 된다. 🌱

 

---

[ 참고 ]

- https://wooaoe.tistory.com/33

[기술면접] TDD(Test-Driven-Development) 방법론에 대해서

- http://clipsoft.co.kr/wp/blog/tddtest-driven-development-%EB%B0%A9%EB%B2%95%EB%A1%A0/

TDD(Test-Driven-Development) 방법론 - CLIPSOFT

- https://media.fastcampus.co.kr/knowledge/dev/tdd/

TDD란? 테스트주도개발에 대한 편견과 실상, 방법론

 

---