일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |
Tags
- Spring Batch
- 엘라스틱서치
- apache storm
- SBT
- Angular2
- Spring XD
- Storm
- scala
- intellij
- Clean Code
- 스프링 배치
- Gradle
- DDD
- design pattern
- Spring Boot
- Linux
- elastic search
- hibernate
- docker
- Java
- Hbase
- Spring
- 인텔리J
- 제주
- hdfs
- hadoop
- spark
- nginx
- 도메인주도설계
- elasticsearch
Archives
- Today
- Total
욱'S 노트
BDD 와 TDD 그리고 사용자스토리 (BDD vs TDD and User Story) 본문
반응형
어느 순간부터 우리는 여러 테스트케이스를 정의할 때 BDD 형식으로 작성을 하는 것이 유행처럼 되어 버렸다. 그러면 BDD가 무엇인지를 정리해보았다.
TDD vs BDD
TDD는 코드 자체의 기능과 안정성에 초점을 맞추는 반면, BDD는 사용자의 행위와 시스템의 동작 방식에 초점을 맞춥니다. 즉, TDD는 "무엇을" 테스트할지에 집중하고, BDD는 "어떻게" 동작해야 하는지에 집중한다.
Gemini에 물어보면 아래와 같이 상당히 잘 정리해준다.
구분 | TDD (테스트 주도 개발) |
BDD (행위 주도 개발)
|
목표 | 코드의 안정성과 품질 향상 |
사용자 요구사항 중심의 개발 및 이해관계자 간 소통 향상
|
초점 | 테스트 케이스 작성 및 코드 구현 |
사용자 행위 및 시스템 동작 방식 정의
|
테스트 표현 | 프로그래밍 언어 기반의 단위 테스트 |
시나리오 기반의 자연어 또는 DSL (Domain Specific Language) 기반 테스트
|
개발 과정 | 단위 테스트 작성 -> 코드 구현 -> 리팩토링 |
요구사항 분석 -> 시나리오 작성 -> 테스트 작성 -> 코드 구현 -> 검증
|
주요 대상 | 개발자 |
개발자, 기획자, 테스터 등
|
테스트 범위 | 주로 단위 테스트 |
단위 테스트, 통합 테스트, 인수 테스트 등 다양한 범위
|
협업 및 소통 | 코드 리뷰 및 단위 테스트 결과를 통해 협업 |
시나리오 기반의 명세 및 테스트를 통해 협업 및 소통
|
예시 | "함수 add(a, b)는 a와 b의 합을 반환해야 한다." |
"사용자가 로그인하면 메인 페이지로 이동해야 한다."
|
- TDD (테스트 주도 개발): 개발자가 코드를 작성하기 전에 테스트 코드를 먼저 작성하는 개발 방법론이다. 작은 단위의 테스트를 반복적으로 수행하며 코드의 안정성과 품질을 높이는 데 초점을 맞춘다.
- BDD (행위 주도 개발): TDD에서 확장된 개념으로, 개발자와 비개발자 간의 소통을 강화하고 사용자 요구사항을 명확하게 정의하는 데 초점을 맞춘다. 시나리오 기반의 테스트를 통해 시스템의 동작 방식을 명세화하고, 이를 기반으로 개발을 진행한다.
둘은 상호 보완적이다. . BDD를 통해 사용자 요구사항을 명확하게 정의하고, TDD를 통해 코드의 안정성과 품질을 확보할 수 있다.
사용자 스토리와 BDD
“Behaviour” is a more useful word than “Test”
BDD는 애자일하고 잘 맞는다. 특히 유저 스토리라 잘맞는다고 한다. 유저스토리는 자연스럽게 테스트케이스로 변환되며 스토리의 시작과 종료를 명확하게 할 수 있다.
As an architect
I want to have up-to-date information about Gitlab issues
So that I can overview and track the issues progress
Feature: Tracking issues progress
As an architect
I want to have up-to-date information about Gitlab issues
So that I can overview and track the issues progress
Scenario: new valid issue webhook is received
Given issue webhook is valid
And issue webhook is authenticated
When it is received
Then a new issue is created
Scenario: new invalid issue webhook is received
Given issue webhook is not valid
When it is received
Then no issue is created
Scenario: new valid unauthenticated issue webhook is received
Given issue webhook is valid
And issue webhook is not authenticated
When it is received
Then no issue is created
And webhook data is saved for future investigation
참조 : gemini
반응형
'Methdology > Agile' 카테고리의 다른 글
사용자스토리 INVEST 원칙 (User Story INVEST Principle) (1) | 2025.03.05 |
---|---|
스크럼과 칸반 차이점 (Scrum vs kanban) (0) | 2025.01.06 |
구글 코드 리뷰가이드 요약 (1) | 2024.12.26 |
성공적인 패어 프로그래밍을 위한 레시피 (0) | 2017.06.07 |