일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- process
- 클래스
- 스레드
- class
- 인스턴스화
- inversion of control
- 오브젝트
- bean
- 부트캠프추천
- social login
- 소셜
- jwt
- 프로세스
- Thread
- 회고록
- API
- 소셜로그인
- 객체
- 인스턴스
- 항해99장점
- 항해99솔직후기
- 객체지향 프로그래밍
- Dependency Injection
- jvm
- 쓰레드
- object
- IoC
- DI
- 항해99단점
- Instance
- Today
- Total
로운's 기술노트
TDD vs BDD vs DDD vs ATDD 본문
■ TDD (테스트 주도 개발, Test Driven Development)
ㅇ 개념
: 테스트가 주도하는 개발로 테스트 코드를 작성하여 검증된 코드를 가지고 실제 코드를 작성하는 애자일의 대표적인 개발 방법론
ㅇ 특징
- 짧은 개발 서클의 반복을 갖는 소프트웨어 개발 프로세스
- 테스트를 통과하는 코드를 작성하고 상황에 맞게 리팩토링
ㅇ 장/단점
- 코드의 가독성 향상 : 각 모듈의 역할이 단순해지고 명확해짐
- 프로젝트의 유지보수와 확장이 용이
- 프로젝트의 품질을 높이고, 효율적인 테스트 경험과 사용자의 입장을 고려한 개발 진행이 가능
- 진입장벽 : 테스트 코드 작성에 대한 학습이 필요하며, 익숙해지는데 많은 시간이 필요
- 작성시간 및 코드량 증가 : 비지니스 로직, 코드 디자인 외에도 테스트 코드를 추가로 작성
■ BDD (행동 주도 개발, Behavior Driven Development)
ㅇ 개념
: 테스트 주도 개발(TDD)에서 파생된 접근 방식으로 비지니스 요구사항까지 생각하고 테스트하며 개발
ㅇ 특징
- TDD를 근간으로 파생된 개발 프로세스
- 비즈니스 요구사항에 집중하여 테스트 케이스를 개발
- 테스트 케이스 자체가 요구사양이 되도록 하는 개발 방식
- TDD를 결합해 시나리오 테스트까지 진행
ㅇ 장/단점
- 높은 가시성 : 프로젝트에 참여하는 모두가 이해하는 간단한 언어를 사용
- 불필요한 테스트 케이스 작성의 비용 절감
- 사용자 만족도 극대화 : 비지니스 요구에 중점을 두는 개발방식
- BDD를 지원하는 소프트웨어 툴이 비교적 적음
- 요구사항이 적절히 설명되어야 한다.
- BDD를 사용하는 테스터들은 충분한 기술이 있어야 한다.
■ DDD (도메인 주도 디자인, Domain Driven Design)
ㅇ 개념
: (비지니스) 도메인이 중심이 되는 개발 방식으로 소프트웨어의 연관된 부분들을 연결하여 계속해서 보완하는 새로운 모델을 만들어 나가 복잡한 어플리케이션을 만드는 것을 쉽게 해 주는 것이 목적이다. 핵심목표는 모듈간 의존성을 최소화하고 응집성을 최대화 하는 것이다.
ㅇ 특징
- 순수한 도메인의 모델과 로직에 집중하는것
- 보편적인 언어의 사용을 추구 (유비쿼터스 언어)
- 상호가 이해할 수 있고 모든 문서와 코드가 동일한 표현과 단어로 구성
- 분석 작업과 설계 그리고 구현까지 통일된 방식으로 커뮤니케이션 가능
- 도메인 모델부터 코드까지 항상 함께 움직이는 구조의 모델을 지향
■ ATDD (승인 테스트 주도 개발, Acceptance Test Driven Development)
ㅇ 개념
: 개발 이전에 사용자, 테스터 및 개발자가 인수조건(Acceptance Creteria)을 정의하는 협업 실천법
ㅇ 특징
- 모든 프로젝트 구성원이 수행해야 할 작업과 요구사항을 정확히 이해할수 있도록 도와줌
- 테스트는 비지니스 도메인 용어로 기술됩니다.
- *인수 테스트(Acceptance Test)의 요구사항을 작성하는 것에 집중
※ 인수 테스트란, 고객이 만들어진 소프트웨어를 실제로 사용하기 전에 테스트
▶ 한눈에 보기
구분 | TDD | BDD | DDD | ATDD |
개념 | 기능 구현에 중심 | 시스템 동작 중심 | (비지니스) 도메인과 모델 중심 |
정확한 요구 사항을 포착하는데 중점 |
참여 | 개발자 | 개발자, 고객, *QA | 개발자, 고객, 도메인 전문가(*PO,*PM) |
개발자, 고객, *QA |
목적 | 단위테스트 작성 | 요구 사항을 이해 | 도메인을 이해 | 수락 테스트를 작성 |
※ QA(Quality Assurance) : 산출물과 소스코드에 대한 품질을 보증하는 담당자
PO(Product Owner) : 제품관리자로 프로젝트를 통해 만들어진 제품에 대한 모든 의사결정권자
PM(Project Manager) : 프로젝트가 성공할 수 있도록 모든 관리 업무를 지휘하는 프로젝트 총책임자
모든 개발 방법론은 하나만 선택하는 것이 아니라 상호 보완적이다.
따라서 맡은 프로젝트에 따라 유동적으로 진행이 가능하다.
[출처]
https://www.browserstack.com/guide/tdd-vs-bdd-vs-atdd
https://blog.naver.com/rkdudwl/221973507455
https://mingule.tistory.com/43
'항해99_'22.01~04 > 개념' 카테고리의 다른 글
Process, Thread가 뭘까? (0) | 2022.04.26 |
---|---|
클래스, 객체, 인스턴스를 알아보자 (0) | 2022.04.26 |
Servlet과 JSP 차이 (0) | 2022.02.01 |
Rest API의 put과 patch의 차이 (0) | 2022.01.25 |
JPA란? (0) | 2022.01.22 |