TDD
Test Driven Development
TDD는 테스트 주도 개발로 매우 짧은 개발 서클의 반복을 가지는 소프트웨어 개발 프로세스이다.
요구되는 기능에 대해 테스트 케이스를 작성하고, 짧으며 가독성이 좋다. 유지보수하기 좋은 코드를 작성할 수 있다.
장점
기존 기능이 정상 동작하는지 확인 가능
코드 리팩토링
코드가 많아지는 경우 기능별로 함수를 나누게 된다.
이 과정에서 코드가 중심을 잡아줄 수 있다.
리팩토링과 동시에 테스트를 수행하면 의존성 문제도 해결할 수 있다.
단점
코드량 증가
진입장벽이 있다
테스트 코드 작성에 대한 학습이 필요하다.
DDD
Domain Driven Design
소프트웨어의 복잡성을 최소화해준다.
DDD의 핵심 목표는 모듈간의 의존성을 최소화하고, 응집성은 최대화하는 것이다.
도메인 모델의 영역
PRESENTATION LAYER
표현 또는 UI 영역. 사용자의 요청을 받아 응용 영역에 전달하고, 응용 영역의 처리결과를 다시 사용자에게 보여주는 역할을 한다.
APPLICATION LAYER
응용 영역. 시스템이 사용자에게 제공해야할 기능을 구현한다.(Service 영역)
DOMAIN LAYER
도메인 영역. 도메인 모델을 구현한다.(이름, 주소, 상품, 주문서 등)
INFRASTRUCTURE LAYER
구현기술에 대한 것을 다룬다.(외부 API, 데이터베이스, 외부 라이브러리 등)
BDD
Behavior Driven Development
BDD는 행동 주도 개발로 TDD에 DDD의 스타일을 적용해 생겨났다.
테스트 케이스 자체가 요구사양이 되도록 개발하는 방식이다.
TDD에서는 단위 테스트로 작성된 테스트 코드의 가독성을 높이고 테스트 케이스에 대한 문서를 작성하였으나,
BDD는 이걸 통합테스트와 시나리오 테스트까지 확장해 각각에 해당하는 문서를 대체한다.
테스트 메소드의 이름을 이 클래스는 어떤 행위를 해야한다 라는 식의 문장으로 작성하여 행위를 위한 테스트에 집중한다.
참고자료
