행위 주도 개발

행위 주도 개발 (BDD) = 인수 테스트 주도 개발 (ATDD)

 

인수 테스트 주도 개발 ?

사용자가 개발자가 만든것을 받아서 사용자 요구사항에 맞는지 확인하는 테스트

이전에 배웠던 요구사항 분석, 유스케이스 다이어그램, 블랙박스(테스트 케이스), 화이트박스(코드 커버리지) , 테스트 주도 개발 은 개발자 관점이다! → 단위 테스트 필요

 

BDD란?

행위 주도 개발로 사용자 기능 위주이다. 고객과 기획자, 설계자, 구현자, 테스터들이 대화를 하면서 기능을 기술 (기능적인 측면)

목적은 고객의 요구사항을 맞추기 위해서 올바른 소프트웨어 개발

 

방법 ?

고객의 요구사항을 구체적인 사례(값)를 사용

고객과 개발자간의 지속적인 소통, 요구사항 개선 조정 및 이해 공유

 

 

🚨소프트 웨어 철학! 🚨

개방, 공유, 참여

이해 당사자들에게 개방하고 공유하고 고객도 참여시키고!

(소프트웨어는 구체적이고 귀납적인 사고방식이 필요하다!

 

 

공통언어의 필요성 중요성

• 프로젝트 관련자 도메인 (고객 비즈니스팀 → 요구자, 개발자 → 응답자)

비즈니스 팀? 솔루션 제품 소유자, 고객을 대표해주는 사람, 기획자

• 비즈니스 팀과 개발팀의 공동 작업 해야한다. 요구사항 분석(비즈니스팀), 설계 구현(개발자), 테스트(테스터)
• 시스템의 오류 발생 원인은 모호성과 서로 다른 해석으로 생긴다. 따라서 명확하고 구체적인 요구사항이 필요하다.
• 비즈니스팀 구성원이 이해할 수 있을 만큼 단순한 언어가 필요하고, 개발팀에게 모호성을 제거할 만큼 명시적이어야한다.

BDD 프로세스

1. 구현할 사용자 스토리를 선정 후 비즈니스 분석가, 개발자, 테스터가 함께 인수 기준 작성
2. 시나리오를 이용하여 인수 기준 설명 (Gherkin 사용)
3. 인수 기준을 이루는 하나의 시나리오 선정
4. 시나리오 실행
5. 시나리오가 실패하면 성공할때까지 코드 작성
   1. 실패하는 단위 테스트 작성
   2. 단위 테스트를 통과하는 코드 작성
   3. 필요할 때에 리팩토링 수행(테스트 주도개발은 행위 주도 개발의 한 컴포넌트가 된다!)
   4. → TDD 구현 (개발자 관점에서 단위테스트)
6. 모든 시나리오가 만족할 때 까지 3~5번 반복

 

Gherkin ?

요구사항 및 시나리오를 설명하고 자연어를 사용하는 간단하고 구조화된 언어

표현방식?

<Feature> : 사용자를 위한 기능을 간단히 요약

<Story> : 시나리오의 개요 (추상적이고 포괄적임)

<Scenario 1,...,n> : 시나리오

<Given> : 액션하기 위한 주어진 상황, 사전 조건

<When> : 사용자가 하는 주요 행위 (and 조건으로 일련의 행위를 늘릴 수 있다)

<Then> : 시스템의 예상 결과

→ 시나리오를 많이 기술하면 구체적이고 명시적이게 된다.

 

 

BDD와 TDD? 🤔

BDD❓

사용자 관점으로 상위 요구사항이다.

사용자가 원하는 스토리를 기술하고 다양한 시나리오를 사용해서 인수 기준을 얻는다. 사용자와 개발자가 이해할 수 있는 언어로 표현한다.

 

TDD❓

개발자 관점으로 하위 요구사항이다.

단위 테스트를 작성하고 시스템 동작보다 구현 내역에 의존

BDD + TDD : 올바른 것을 올바르게 개발하는 것을 보장