[소프트웨어공학] TDD와 BDD

Computer Science/Software Engineering 2024. 1. 17. 10:00

728x90

TDD

TDD(Test-Driven Development, 테스트 주도 개발)는 소프트웨어 개발 방법론 중 하나로, 선 개발 후 테스트 방식이 아니라 선 테스트 후 개발 방식의 프로그래밍 방법을 말한다. 즉 테스트 코드를 작성한 후 테스트를 통과하기 위한 코드를 개발하는 방식이다. 반복 테스트를 위한 소프트웨어 방법론으로 작은 단위의 테스트를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.

TDD를 이용한 개발 방법

1. 테스트 케이스 작성

만들고 싶은 기능을 점검할 테스트 코드를 작성한다. 이때 아직 기능 코드를 구현하지 않았으므로 테스트 결과는 실패로 반환된다. 실패하는 테스트를 가장 빠르게 구현하는 방법은 아무 값이나 반환하도록 하는 것이다.

2. 테스트 케이스를 통과하는 코드 작성

테스트 코드를 만족시킬 수 있는 기능을 구현한다. 테스트 통과를 최우선으로 생각하며 작업한다. 즉, 단위 테스트를 통과할 수 있을 정도의 최소한의 코드만 작성한다.

3. 작성한 코드 리팩토링

기능의 성능이 향상되며, 재사용성이 좋고, 가독성이 좋은 코드로 기능 코드를 개선한다. 테스트 코드를 통해 다시 기능 코드를 점검한다. 기능 테스트가 완전해질 때까지 2, 3의 과정을 반복한다.

좋은 TDD의 특징 (FIRST 규칙)

Fast : 테스트는 빠르게 동작하여 자주 실행할 수 있어야 한다.
Independent : 각각의 테스트는 독립적이며 서로 의존해서는 안된다.
Repeatable : 어느 환경에서도 반복할 수 있어야 한다.
Self-Validating : 테스트는 성공 또는 실패로 bool 값으로 결과를 내어 자체적으로 검증되어야 한다.
Timely : 테스트는 적시에 즉, 테스트하려는 실제 코드를 구현하기 직전에 구현해야 한다.

TDD의 장점

요구 사항 분석 → 설계 → 개발 → 테스트 → 배포와 같은 일반적인 개발 방식은 초기 설계 이후 요구사항 변경으로 인한 재설계가 필요할 때 유지보수가 어려워진다. 재설계로 코드를 삽입, 수정, 삭제하는 과정에서 불필요한 코드가 남거나 중복처리가 될 수 있고, 코드 재사용성이 어려워진다. 작은 부분을 수정해도 전체를 테스트 해야 하기 때문에 버그를 검출하기 어려워져 테스트 비용이 증가한다.

TDD는 테스트 → 코드 개발의 반복적인 단계로 일반적인 개발 방식의 문제점을 해결한다.

객체지향적인 코드 개발

TDD를 통한 소프트웨어 개발 시 기능 별로 모듈화가 이루어진다. 유닛 단위로 테스트를 하면 유닛 간의 종속성을 낮출 수 밖에 없다. 이는 의존성과 종속성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하며, 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치지 않게 된다.

재설계 시간의 단축

테스트 코드를 먼저 작성하기 때문에 개발자가 무엇을 해야하는지 분명히 정의하고 개발을 시작하게 되며, 테스트 시나리오에서 다양한 예외 상황을 생각해볼 수 있다. 이는 개발 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있다.

유지 보수(리팩토링)의 용이성

기본적으로 단위 테스트 기반의 테스트 코드를 작성하기 때문에 추후 문제가 발생했을 때 각 모듈별로 테스트를 진행해보면 문제의 지점을 쉽게 찾을 수 있다.

디버깅 시간 단축

유닛테스트를 전제하므로 특정 버그를 쉽게 찾아낼 수 있다.

추가 구현이 용이

개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 유닛테스트를 통해 테스트 기간을 단축시킬 수 있다.

TDD의 단점

생산성 저하

이미 알고있는 예외 상황의 경우 개발 기간이 타이트하게 잡힌다면, TDD를 이용해 테스트 코드를 작성하고 그에 통과하기 위한 코드를 작성한다면 비효율적일 것이다.

사전 준비 기간

TDD를 프로젝트에 도입하려면 사전에 필요한 지식을 습득하고 개발 환경을 구축해야한다.

TDD에서 테스트 케이스를 작성하고 고민하는 것은 시간이라는 비용이 든다. 이를 이미 작성된 요구 사항이나 기획서를 바탕으로 테스트 케이스를 생성하여 비용을 줄이는 방식이 BDD이다.

BDD

BDD는 행동 주도 개발(Behavior Driven Development)로 사용자 행위를 정의하고 그 정의에 따라 개발해나가는 방법이다. TDD에서 하나 더 나아가 테스트 케이스 자체가 요구 사항이 되도록 하는 개발 방법이다. TDD를 개발할 때 테스트케이스를 작성하는 것은 기능에 대해 매번 예외사항을 생각해야 하기에 비용이 많이 들어가는 작업이다. 이때 BDD를 사용하면 이미 작성된 요구 사항이나 기획서가 있을 때 이에 맞추어 테스트케이스를 작성하여 시간 비용을 줄일 수 있다. 즉 BDD는 TDD에서 파생된 개발 방법론으로 개발자와 비개발자의 협업 과정을 녹여낸 방법이다.

BDD 기본 패턴

BDD는 시나리오를 기반으로 테스트 케이스를 작성하며 함수 단위 테스트를 권장하지 않고, 시나리오는 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 레벨을 권장한다.

Given : 시나리오 진행에 필요한 값을 설정한다. (주어진 환경)
When : 시나리오를 진행하는데 필요한 조건을 명시한다. (행위)
Then : 시나리오를 완료했을 때 보장해야 하는 결과를 명시한다. (기대 결과)

TDD와 BDD의 차이

TDD와 BDD는 테스트의 관점에 차이가 있다. TDD의 테스트는 테스트할 모듈의 기능을 확인한다면, BDD의 테스트는 시나리오 주체를 기준으로 행위를 확인한다. 예를 들어 덧셈을 계산하는 함수가 있을 때 TDD의 테스트는 add(1,1)이 2인지 확인한다면, BDD의 테스트는 사용자가 =를 눌렀을 때 1+1의 값 2가 화면에 표시되는지 확인한다.

BDD는 TDD에서 파생된 개념으로 TDD의 관점에서 보기 어려운 유저 시나리오를 확인 가능하다. BDD는 테스트 케이스로 시나리오를 검증하고 해당 시나리오에서 사용되는 각 모듈들을 TDD의 테스트케이스로 검증하여 기대하는 테스트 커버리지를 얻을 수 있다. TDD와 BDD 둘 중 하나를 선택하는 것이 아니라 둘은 상호 보완적인 관계이다.

	TDD (Test Driven Development)	BDD (Behavior Driven Development)
테스트 코드의 목적	기능 동작의 검증	서비스 유저 시나리오 동작의 검증
테스트 코드의 설계 중심	제공할 모듈의 기능 중심	서비스 사용자 행위 중심
테스트 코드 설계 재료	모듈 사양 문서(개발자가 작성)	서비스 기획서(서비스 기획자가 작성)
적합한 프로젝트	모듈/라이브러리 프로젝트	서비스 프로젝트
장점	설계 단계에서 예외 케이스들을 확인할 수 있다.	설계 단계에서 누락된 기획을 확인할 수 있다.