개발 방법론에 대해 알아보자

어쩌다 TDD 방법론에 대해 듣게 되어서 대체 개발 방법론이 무엇인지 궁금했었다.

그래서 찾아보니 어떤 분이 블로그에

"소프트웨어를 생산하는 데 필요한 프로그래밍 개발 과정들을 정리하고 표준화하여

프로그래머들이 프로그래밍 개발과정에서 각 개인이 개발과정에서의 일관성을 유지하고

프로그래머들 간의 효과적인 협업이 이루어질 수 있도록 돕기 위한 방법론"

라고 잘 요약해주셨다.

즉, 소프트웨어 개발 방법론은 소프트웨어를 어떤 방식으로 만들어 갈지에 대한 것이다.

매우 다양한 방법론이 있으며 개발자들은 개발 상황에 맞는 방법론을 선택하면 된다.

이번 게시물에서는 여러 방법론들 중에서 TDD, BDD, DDD에 대해 정리해 보았다.

 

 

 

✨ TDD(테스트 주도 개발, Test-Driven Development)

일반적으로 개발을 할 때 코드를 작성하고 테스트를 하게 된다.

그러나 TDD는 테스트 코드를 먼저 작성하고 프로그램 코드를 작성하는 과정을 거친다.

TDD 프로세스는 다음과 같은 3가지 단계로 나눌 수 있다.

1. RED(테스트 실패)

구체적인 하나의 기능에 대한 하나의 테스트를 추가하며, 테스트가 실패하는지 확인하는 단계이다.

테스트가 실패해야지 해당 테스트가 신뢰성이 있다고 할 수 있다.

이때, 실패 이유는 테스트 코드의 문제가 아니어야 한다.

 

2. GREEN(테스트 성공)

모든 테스트에 대해 코드가 성공하도록 코드를 수정하는 단계이다.

테스트 성공을 위해 최소한의 코드 변경이 이루어져야 한다.

만약 필요 이상으로 코드가 변경되게 되면, 다른 단계에 악영향을 끼칠 수 있기 때문이다.

 

3. REFACTOR(리팩토링) 

코드 베이스를 정리하고, 가독성 · 적용성 · 성능을 고려하여 구현 설계를 개선한다.

 

그래서 TDD 방법론을 통해 개발을 진행할 경우 이 사이클을 계속 반복한다.

 

그렇다면 TDD로 개발하였을 때 장점은 무엇일까?

- 코드가 완성되어 개발자 손을 떠나기 전에 빠르게 피드백이 가능하다.

- 사용자에게 도달하기 전에 테스트를 통해 문제를 인지할 수 있다. 따라서 코드의 불안정성을 개선하고, 생산성을 높일 수 있다.

- 기능 단위로 테스트를 진행하고, 최소한의 코드 변경을 지향하기 때문에 오버 코딩을 방지할 수 있다.

- 개발 과정이 테스트 코드로 남기 때문에, 과거 의사결정을 확인하기 쉽다.

 

그렇지만 TDD가 무조건 좋은 것은 아니다.

테스트를 만들어야 하는 만큼 그냥 개발할 때보다 더 많은 시간과 리소스를 필요로 한다.

하지만 시간이 지날수록 비용이 일정하게 유지되어 장기적으로는 유리하다고 할 수 있다.

 

그렇다면 Node.js에서는 어떻게 테스트 코드를 돌려볼까?

바로 mocha를 이용하면 된다!

mocha는 TDD 개발을 위한 프레임워크로 js로 작성한 테스트 코드를 테스트할 수 있게 도와준다.

 

 

 

🎇 BDD(행동 주도 개발, Behavior-Dirven Development)

BDD는 TDD에서 파생된 개발 방법론이다.

기능 단위로 테스트 케이스를 만들었던 TDD와 다르게, BDD는 시나리오를 기반으로 테스트 케이스를 작성하며 함수 단위 테스트를 지양한다.

 

하나의 시나리오는 Feature, Scenario, Given, When, Then 을 가진다.

- Feature: 테스트에 대상의 기능/책임을 명시한다.

- Scenario: 테스트 목적에 대한 상황을 설명한다.

- Given: 시나리오 진행에 필요한 값을 설정한다.

- When: 시나리오를 진행하는데 필요한 조건을 명시한다.

- Then: 시나리오를 완료했을 때 보장해야 하는 결과를 명시한다.

 

이것을 개발에 적용하면 테스트 대상의 상태 변화를 테스트하는 것이라 할 수 있다.(Given → When → Then)

즉, 테스트 대상은 특정 상태에서 시작하여(Given) 어떤 변화를 주었을 때(When) 기대하는 상태로 완료되어야 한다. (Then)

 

 

 

🎆 DDD(도메인 주도 개발, Domain-Driven Development)

DDD란 여러 도메인들의 상호작용을 통해 설계하는 방법이다.

 

네이버 포털사이트에 대해 생각해보자.

- 블로그를 관리하는 도메인

- 카페를 관리하는 도메인

- 뉴스를 관리하는 도메인

등등 여러가지 도메인들이 존재할 것이다.

 

이때 블로그를 관리하는 도메인과 뉴스를 관리하는 도메인이 가진 정보들은 확연히 다를 것이다.

그래서 각자의 상황을 구별하는 것이 중요하고, 이 상황을 Bounded Context 라고 한다.

Bounded Context에 따라 모델의 역할이 달라질 것이다.

그리고 이 Bounded Context와 모델을 외부에 공개하지 않고, private하게 갖는다.

즉, 도메인을 서비스별로 분리하여 개발하는것이 DDD의 핵심이다.

 

그렇기 때문에 직접적으로는 서로 다른 도메인 영역(Bounded Context)에 영향을 끼칠 수 없고, API 호출을 사용하여야 한다.

이를 통해 도메인들은 서로 완전하게 분리되고, 변경과 확장에 대해 유리해진다.

 

DDD 프로세스 역시 크게 3가지 단계로 이루어진다.

1. Application Layer

주로 도메인과 Repository를 바탕으로 실제 서비스(API)를 제공하는 계층이다.

 

2. Domain Layer

Entity, VO(Value Object)를 활용하여 도메인 로직이 진행되는 계층이다.

Entity는 primary key(고유 식별자)를 바탕으로 객체의 정체성을 부여한다.

VO는 상태를 바탕으로 객체의 정체성을 부여한다.

 

3. Infrastructure Layer

외부와의 통신(ORM, DB, NoSql)을 담당하는 계층이다.

 

 

 

 

 

---

reference

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

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

https://www.popit.kr/bdd-behaviour-driven-development%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B0%84%EB%9E%B5%ED%95%9C-%EC%A0%95%EB%A6%AC/

BDD (Behaviour-Driven Development)에 대한 간략한 정리 | Popit

https://huisam.tistory.com/entry/DDD

DDD(Domain Driven Design) - 도메인 주도 설계란? 마이크로서비스의 관점에서