SDM - TDD, BDD, DDD 란? (feat.RDD)

강정우·2024년 3월 30일

자습

목록 보기

11/11

요즘 트렌드

요즘 개발자들 사이에서 주로 사용하는 언어들을 보면, " TDD와 DDD로 개발을 진행한다 " 라는 말을 들을수 있다.
그리고 이에 더해 추가로 BDD, RDD 에 대해서 도 알아보자.

Software Development Methodology 의 TDD, BDD, DDD 소개

소프트웨어 개발 방법론( Software Development Methodology )에는 다양한 접근 방식이 있으며, TDD(Test-Driven Development), BDD(Behavior-Driven Development), DDD(Domain-Driven Design), RDD(Readme-Driven Development)는 그 중 일부이다.

각각의 방법론은 소프트웨어 개발 과정에서 특정한 초점을 두고 있으며, 개발자들이 보다 효율적이고 체계적으로 프로젝트를 진행할 수 있도록 돕는다.

1. TDD (Test-Driven Development)

정의

TDD는 테스트가 개발을 주도해 나가는 개발 방법론이다.
즉, 비즈니스 코드를 작성하기 전에 테스트 코드를 먼저 작성하고, 이 테스트 코드가 통과되도록 비즈니스 코드를 작성하는 방식이다.

장점

코드의 오류를 빠르게 발견하고 수정할 수 있으며, 리팩토링과 코드 품질 향상에 기여함.

단점

초기 테스트 코드 작성에 시간이 많이 소요됨.

TDD 작성순서

작은 단위의 테스트 작성
빠른 테스트 통과를 위해 프로덕션 코드 작성
테스트 코드 작성
새로운 테스트 코드 통과를 위한 프로덕션 코드 추가 및 수정
1~4단계를 반복하여 실패/성공 케이스 작성
개발 코드에 대한 중복을 제거하며 리팩토링

TDD의 unit test 작성 꿀팁
빠른 테스트 통과를 위한 가짜 정답을 구현
값이 다른 여러 테스트를 작성하고 이를 일반화하여 정답 구현하는 삼각층량법
정답을 바로 구현

개발자로서 프로그램을 작성할 때, 기능 구현과 함께 고려해야 하는 것은 가독성을 위한 coding convention, 즉 앞으로 서비스 확장에 따른 유지보수를 고려해야 한다. 이를 위해 리팩토링과 테스팅이 필수적인데, 해당 과정에서 발생하는 기능에 대한 오류와 이미 생성된 객체에 대한 네이밍 등에 대한 어려움을 TDD 방법론에서 이미 작성한 테스트 코드로 인해 안정적인 리팩토링을 진행할 수 있는 것이다.

coding convention - 내가 작성한 코드를 다른 사람이 쉽게 이해할 수 있도록 가독성 있는 코드를 작성하는 규칙

2. BDD (Behavior-Driven Development)

정의

BDD는 소프트웨어의 기능이 어떻게 행동해야 하는지에 초점을 맞춘 개발 방법론이다.
사용자의 행동과 요구사항을 명확한 언어로 정의하여, 이를 기반으로 테스트 코드와 비즈니스 로직을 개발한다.

장점

비개발자(예: 비즈니스 분석가, 제품 관리자)도 이해할 수 있는 명확한 요구사항 정의가 가능함.

단점

BDD를 위한 도구나 프레임워크에 익숙해지는 데 시간이 필요할 수 있음.

BDD 예제: 온라인 쇼핑 카트

온라인 쇼핑 사이트에서 사용자가 상품을 카트에 추가하는 기능을 개발한다고 가정해 보자.
BDD 접근 방식을 사용하여 이 기능을 개발하는 과정은 다음과 같다.

1. 시나리오 정의

"사용자가 상품을 카트에 추가할 수 있다" 는 비즈니스 요구사항을 기반으로 시나리오를 작성한다.
그리고 Given, When, Then 의 순서를 먼저 작성하고 그에 맞는 행동을 작성한다.

Given: 사용자가 온라인 쇼핑 사이트에 로그인했을 때,
When: 사용자가 상품을 카트에 추가하려고 할 때,
Then: 해당 상품이 카트에 성공적으로 추가되어야 한다.

@ExtendWith(SpringExtension.class)
public class ShoppingCartTest {

    @BeforeEach
    public void setUp() {
        // Given: 사용자가 온라인 쇼핑 사이트에 로그인했을 때,
        // 사용자의 쇼핑 카트를 초기화
        cart = new ShoppingCart();

        // 상품 초기화
        product = new Product();
        product.setId(1L);
        product.setName("Test Product");
        product.setPrice(100.0);
    }

    @Test
    public void whenUserAddsProductToCart_thenProductIsAddedSuccessfully() {
        // When: 사용자가 상품을 카트에 추가하려고 할 때,
        cart.addProduct(product, 1); // 상품과 수량을 추가.

        // Then: 해당 상품이 카트에 성공적으로 추가되어야 함.
        assertThat(cart.getItems()).hasSize(1);
        assertThat(cart.getItems()).extracting("product").contains(product);
        assertThat(cart.getTotalPrice()).isEqualTo(100.0);
    }
    
}

2. 테스트 작성

위 시나리오를 기반으로 자동화된 테스트를 작성한다. 이 테스트는 당연히 초기에는 실패한다(TDD의 원칙에 따라).

3. 코드 구현

테스트를 통과할 수 있도록 실제 기능을 구현.

4. 리팩토링

필요한 경우 코드를 개선하고, 모든 테스트가 통과하는지 확인한다.

BDD는 이처럼 비즈니스 요구사항을 명확하게 이해하고, 이를 바탕으로 테스트와 개발을 진행함으로써, 개발 초기 단계부터 비즈니스 목표와 일치하는 소프트웨어를 만들 수 있도록 돕는다.

3. DDD (Domain-Driven Design)

정의

DDD는 복잡한 요구사항을 가진 소프트웨어 프로젝트에서, 핵심 비즈니스 개념(도메인)을 중심으로 설계와 개발을 진행하는 방법론이다.
도메인 전문가( 해당기술 고문 )와 개발자가 긴밀하게 협력하여 데이터 주도 설계로, 비즈니스의 복잡성을 관리하고 해결한다.

데이터 주도 설계
데이터 주도 설계란 객체가 가져야 할 데이터에 초점을 두고 설계하는 방식을 말한다.
데이터 주도 설계에서는 객체 자신이 포함하고 있는 데이터를 조작하는데 필요한 행동을 정의한다.

장점

비즈니스 로직과 요구사항의 복잡성을 효과적으로 관리할 수 있다.

단점

DDD를 적용하기 위해서는 도메인에 대한 깊은 이해와 분석이 필요하다.

DDD 예제: 온라인 쇼핑 도메인

온라인 쇼핑 시스템을 개발한다고 가정해 보자.
이 시스템은 여러 하위 도메인으로 나눌 수 있다. 예를 들어, "상품", "주문", "결제" 등등
그리고 각 하위 도메인은 도메인 모델을 통해 추상화되고, 이 모델들은 시스템의 전체 설계를 이끈다.

예를들어
상품 도메인: 상품 정보, 재고 관리, 카테고리 분류 등을 관리.
주문 도메인: 고객의 주문 처리, 주문 상태 관리, 배송 정보 관리 등을 담당.
결제 도메인: 결제 처리, 결제 방식 관리, 결제 검증 등의 기능을 포함.

이러한 도메인 중심의 접근 방식은 복잡한 시스템을 더 잘 이해하고, 관리할 수 있게 해준다. 또한, 비즈니스 요구사항의 변화에 유연하게 대응할 수 있는 설계를 가능하게 한다.

도메인 주도 설계(DDD)는 비즈니스의 본질적인 복잡성을 이해하고, 이를 기반으로 소프트웨어를 설계하는 데 큰 도움을 준다. DDD를 통해 개발자와 비즈니스 전문가 간의 커뮤니케이션을 강화하고, 유연하며 확장 가능한 소프트웨어를 만들 수 있다.

🥊 BDD VS DDD ? 🥊

BDD(Behavior-Driven Development, 행동 주도 개발)와 DDD(Domain-Driven Design, 도메인 주도 설계)는 소프트웨어 개발과 설계에 있어 서로 다른 초점을 두고 있다.
하지만 현업에서는 둘 중 하나를 채택하는 것이 아닌, 함께 사용되어 프로젝트를 더 완성도 있게 구현하기도 한다.

간단하게 다시 한 번 정리하자면

BDD (행동 주도 개발)

접근 방식: 앞서 BDD는 비즈니스 요구사항을 이해하기 쉬운 언어로 표현하고, 이를 바탕으로 "Given-When-Then"과 같은 형식을 사용하여 시나리오를 정의하고 테케를 작성한다고 하였다.
주요 이점: 비즈니스 요구사항과 개발 사이의 간극을 줄이고, 모든 이해관계자가 요구사항을 명확하게 이해할 수 있도록 돕고 또 테스트 주도 개발(TDD)의 원칙을 확장하여 행동 기반 테스트를 통해 더 높은 품질의 소프트웨어를 개발할 수 있다.

DDD (도메인 주도 설계)

접근 방식: DDD는 도메인 모델을 중심으로 시스템을 설계한다. 이 과정에서 유비쿼터스 언어(Ubiquitous Language)를 사용하여, 개발자와 비즈니스 전문가 간의 의사소통을 원활하게 한다. 도메인 모델은 비즈니스의 핵심 로직과 규칙을 반영하며, 이를 기반으로 시스템의 구조를 결정한다.
주요 이점: 복잡한 시스템을 효과적으로 설계하고, 비즈니스 도메인의 본질을 반영한 소프트웨어를 개발할 수 있다. 또한, 도메인 중심의 접근 방식은 시스템의 유지보수성과 확장성을 향상시킨다.

BDD와 DDD의 결합

BDD와 DDD는 서로 보완적인 관계에 있기때문에 DDD를 통해 도메인 모델을 정의하고, 이를 기반으로 BDD 접근 방식을 사용하여 비즈니스 요구사항을 명확한 행동으로 변환하고 테스트를 수행함으로써, 비즈니스 요구사항을 정확히 이해하고 반영하는 고품질의 소프트웨어를 개발할 수 있다. 이러한 결합은 개발 과정에서의 오해를 줄이고 모든 이해관계자가 동일한 목표를 향해 나아갈 수 있도록 돕는다.

+ RDD (Readme-Driven Development)

정의
RDD는 개발을 시작하기 전에 README 파일을 먼저 작성하는 개발 방법론.
프로젝트의 목표, 설계, 사용 방법 등을 미리 문서화함으로써, 개발 방향성을 명확히 하고 이해관계자 간의 커뮤니케이션을 용이하게 한다.
장점
프로젝트의 목적과 방향성을 초기에 명확히 할 수 있음.
단점
실제 개발 과정에서 변경사항이 발생할 경우, 문서를 지속적으로 업데이트해야 하는 부담이 있음.

https://slaks1005.tistory.com/61
https://hanamon.kr/tdd%EB%9E%80-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%A3%BC%EB%8F%84-%EA%B0%9C%EB%B0%9C/
http://clipsoft.co.kr/wp/blog/tddtest-driven-development-%EB%B0%A9%EB%B2%95%EB%A1%A0/
https://giron.tistory.com/43

강정우

智(지)! 德(덕)! 體(체)!

이전 포스트