본론에 앞서 알아둬야 할 개념
Feature : 테스트에 대상의 기능/책임을 명시한다.
Scenario : 테스트 목적에 대한 상황을 설명한다.
Given : 시나리오 진행에 필요한 값을 설정한다.
When : 시나리오를 진행하는데 필요한 조건을 명시한다.
Then : 시나리오를 완료했을 때 보장해야 하는 결과를 명시한다.
BBD & SSD를 사용하는 이유
프로그램의 흐름을 생각해보자.
프로그램은 0과1로 이루어져 있으며 이를 우리는 '데이터'라고 칭한다.
프로그램은 '데이터'의 지속적인 변화라고 볼 수 있다.
우리는 데이터를 사람이 이해할 수 있도록 표기한다. (ex. String, Object, Array 등등)
이러한 Object Data는 화면으로 render되며, 이렇게 만들어진 View를 사용자는 보게 된다.
또한, 사용자는 위의 View를 사용하며 끊임없는 Action을 하고, 새로운 Data를 끊임없이 만들어낸다.
위를 정리하면 프로그램의 흐름에는 두가지가 존재한다.
- Data -> User
- User Action -> Data변화
BDD & SDD 란?
위의 개념을 통해 BDD & SDD 를 정의해보자.
BDD - Behavior Driven Development
--사용자의 행동을 중심으로 설계 및 개발을 함
SDD - Schme Driven Development
-- 데이터 구조를 중심으로 설계 및 개발을 함
BDD & SDD로 Task 작성하기!
BDD
하나의 Feature를 여러개의 story로 만들고, given - when - then의 형식으로 task를 작성하여, 이를 기반으로 테스트를 하고, 개발을 진행하는 방식
SDD
개발 진행 전, 필요 Data를 찾고, 구조설계 이후 Schema(데이터구조)중심으로 개발을 진행하는 방식
BDD 작성하기!!
when -> then -> given
사용자가 쏘주추가요 버튼을 누르게 된다면 기존 계산서에서 소주가 +1 된다고 가정하자.
여기서 when은 버튼을 클릭하는 행위를 나타낸다. when을 통해 일어나는 결과가 then이 되는 것이다.
하지만 사용자의 동작에 따라 then이 하나보다 많은 경우를 가질 수 있는 경우도 존재한다.(사실 이게 일반적임)
우리가 버튼을 클릭하게 되면, 일반적으로 소주를 받아야 할 것이고, 소주 뚜껑을 따야 할 것이며, 잔에 따르고, 들고있던 소주를 테이블에 내려놓을 것이다.
then을 기술한다면, 가급적 모든 경우의 수를 생각하여 작성하는게 좋다. (즉, 데이터가 바뀌는 단위로 적어주면 좋다.)
그런데 만약, 쏘주추가요 버튼을 클릭했는데, 만약 소주가 매진인 상태라면?
이럴때 사용할 수 있는게 given이다.
given은 같은 동작을 했을때, 번외의 결과가 나올 경우 조건을 적어준다.
정리
given : 소주가 1개 이상인 경우에
when : 쏘주추가요 버튼을 클릭한다.
then :
->계산서에 소주가 1개 추가된다.
->소주를 받는다.
->소주 뚜껑을 딴다.
->잔에 따른다.
->들고있던 소주를 내려놓는다.
1Then = 1Task
위와 같이, then은 보통 여러개로 존재한다.
then이 프로젝트 진행상황을 체크할 수 있는 하나의 단위가 되는 것이다.
위와같이 세부적인 then을 비슷한 덩어리로 구성해놓으면 이는 곧 task로 볼 수 있고, 이를 진척도의 기준으로 세우기에 적합하게 되는 것이다.
프로젝트 진행 상황에 따라 다음엔 SSD로 돌아오겠습니다
