테스트 주도 개발 TDD와 BDD, DDD

TDD (Test-Driven Development)

 

■ TDD 방법론이란?

 

TDD 방법론은 짧은 개발 서클을 반복하는 소프트웨어 개발 프로세스로 프로그램의 소스코드를 작성하기 전에 테스트 케이스를 먼저 작성하는 순서로 개발을 진행하도록 한다. 요구사항에 해당하는 테스트 케이스를 작성하고 이를 통과할 수 있는 짧은 코드를 작성한다. 그리고 이 코드를 리팩토링하는 과정을 반복하여 프로그래밍을 진행한다.

 

TDD 방법론은 개발자가 새로운 기능에 대한 테스트 케이스를 먼저 작성하는 것이 더 좋은 소프트웨어를 만들어내고 프로젝트를 보다 빠르게 완료할 수 있지 않을까라는 생각에서 생각에서 비롯되었다. 이는 기존의 product 코드를 먼저 작성하는 이를 테스트 했던 것과는 다른 접근이다.

 

기존에는 새로운 기능을 추가하게 되면 기존의 기능이 제대로 동작하지 않는 경우도 있다. TDD 방법론에서는 새로운 기능을 추가하기 전에 이에 해당하는 테스트를 먼저 작성하도록 한다. 이를 통해서 새로운 기능을 추가했을 때 새로운 기능이 잘 작동함과 함께 기존의 기능들도 정상적으로 작동하는지 검증할 수 있다. 또한 소프트웨어의 기능에 대한 테스트 케이스를 먼저 작성함으로써 개발자들이 소프트웨어가 어떻게 작동해야 할지, 이 소프트웨어가 제공해야 할 기능들에 대해서 고려할 수 있도록 해준다.

 

 ■ TDD의 장점

 

TDD 방법론은 '테스트 코드 작성 -> 기능 구현 코드 작성 -> 리팩토링'의 단계를 반복하기 때문에 좋은 코드를 작성하기에 유리하다.

기능에 대한 테스트 코드를 먼저 작성함으로써 시스템에서 발생할 수 있는 오류들을 줄일 수 있다. 또한 짧은 간격으로 기능의 구현과 리팩토링의 과정을 반복하면서 간결하고 깔끔한 코드를 작성하는데 도움이 된다.

 

코드를 작성할 때에는 기능의 구현뿐만 아니라 가독성을 위한 coding convention, 앞으로의 유지보수와 시스템의 확장 등에 대해서 고려해야 한다. 프로그램이 커지다 보면 이러한 부분들의 수정을 위해서 리팩토링을 진행하게 되는데, 리팩토링의 과정에서 발생하는 기능의 오류들에 대한 디버깅이나 이미 생성된 객체들에 대한 네이밍 등에서 어려움을 겪을 수밖에 없다. 하지만 TDD 방법론에서는 이미 작성한 테스트 코드들로 인해서 리팩토링을 통해 변경되는 소스의 기능에 대한 부분에서 보다 안정적인 리팩토링을 진행할 수 있도록 해준다.

 

이 외에도 작성된 테스트 코드를 이 프로그램에 대한 테스트 문서 작성에 사용할 수 있고,  각 기능마다의 테스트를 통해서 소스의 퀄리티를 보증해줄 수 있다. 그리고 작은 단위의 기능부터 개발을 진행하도록 하여서 소스가 유연한 확장성을 가질 수 있도록 해준다.

 

하지만 이러한 장점들을 가진 반면에 TDD 방법론을 진행하면서 발생할 수 있는 단점들도 존재한다.

 

■ TDD의 단점

 

1. 코드 생산성의 문제

테스트 코드의 작성으로 절대적인 코드량이 늘어날 수밖에 없다. 기본적인 시스템 기능 구현 외에 테스트 코드를 추가적으로 작성해야 하기 때문에 프로젝트의 시간이 늘어나게 된다. 또한 개발이 진행됨에 따라 늘어난 테스트 코드들의 관리에 대한 부분도 이슈가 될 수 있다. 이 때문에 일정이 촉박하고 빠른 개발이 필요한 프로젝트에는 TDD를 적용하기 어렵다.

 

2. 테스트 코드 작성의 진입장벽

테스트 코드를 작성하기 위해서는 우리가 만들고자 하는 소프트웨어에 대한 높은 이해도가 필요하다. 어떤 기능을 테스트하고 어떤 방법을 통해서 테스트가 잘 되었는지 검증할지, 어떠한 테스트 프레임워크, 툴을 사용할지에 대한 고민이 필요하다. 이러한 부분들은 쉽게 익힐 수 없는 부분들이다.

 

3. 모든 테스트 코드 작성에 대한 고민

어디까지 테스트 코드를 작성해야 할까? 모든 소스 코드의 기능과 예외사항에 대해서 테스트 코드를 작성하기란 쉽지 않다. 물론 테스트 코드를 작성하면서 시스템 설계의 문제점에 대해서 고민해볼 수 있지만, 때로는 테스트 코드의 작성을 위해서 실제 프로덕트 코드의 구조에 수정이 필요할 경우도 발생할 수 있다.

 

 

BDD (Behavior-Driven Development)

BDD 방법론은 TDD에서 파생된 프로그래밍 개발 프로세스로 Buisiness Requires와 end-user의 관점에서 개발을 진행하는 방법이다. TDD에서 테스트가 각 기능에 대한 유닛 테스트를 작성했다면 BDD는 결합 테스트와 시나리오 테스트까지 확장하여 테스트 케이스 자체가 요구 사양이 되도록 한다.

 

 

DDD (Domain-Driven Design)

DDD 방법론은 각 비즈니스 도메인이 중심이 되어 진행하는 개발 방식으로 소프트웨어의 연관된 부분들을 연결하여 계속해서 진화하는 새로운 모델을 만들어나가 복잡한 애플리케이션을 만드는 것을 쉽게 해주는 것에 있습니다. 도메인 전문가와 IT 개발자 간의 커뮤니케이션과 협업을 통해서 모델을 발전시키는 것을 추구한다.

 

 

<reference>

- Domain Driven Design 이란 무엇인가?

- [개발상식] 22. 테스트 주도 개발에 대하여 - TDD와 BDD 그리고 DDD

- The Value at the Intersection of TDD, DDD, and BDD