6. BDD defined
66
잘 정의된 상태와 상호 작용하는 주기를 설명하며, 중요한
작동 테스트를 거친 SW 를 제공한다
outside-in
pull-based
multiple stakeholder
multiple scale,
high automation
agile methodology
https://en.wikipedia.org/wiki/Behavior-driven_development
7. The power of “should”
77
개발에 완성도를 위한 사용자 관점의 테스트
“Should it really?” 라고 묻도록 독려
삼각 측량에 따른 제품 완성도 함양
구현 결함
충족된 구현의 이상 반응
요구사항에 결함
발생 가능한 요구사항 도출의 결여
9. How does BDD help?
99
모두가 함께 명세와 비즈니스 가치 도출 필요
모두가 이해할 수 ubiquitous language 로 작성
자동화 할 수 있는 acceptance test 로 전환하기
지속적인 빌드를 통한 테스트
모두가 이해할 수 있는 가독성 있는 문서화 도출
Living Documentation
13. ACCEPTANCE CRITERIA
사용자, 고객 또는 시스템 수준의 충족되어야 하는 조건
기능 및 비기능적 요구사항에 대한 명확한 통과/실패 결과
인수 기준은 모든 사람이 이해할 수 있는
사용자 스토리에 대한 시나리오
작업의 독립적인 완료 기준 (What. Not How)
테스트 (현실적인 예제 기반)
기능에 대한 명세
긴밀한 협업 지향
명확한 검토를 통한 개발
신뢰와 확신 구축
고객 중심의 개발
유비쿼터스 랭기지를 통한 공통의 이해 촉진
1313
23. 2323
Cucumber is a tool that supports Behaviour-Driven
Development(BDD)
Write features in plain text
Validates that the software does what those specifications say
Business readable DSL
28. What is Cucumber?
2828
시나리오에는 Step 목록이
존재하며 이를 통해
테스트를 수행한다.
Cucumber 시나리오를
이해하기 위해서는 기본
문법과 규칙을 사용해야
하며 이를 Gherkin 이라
부른다.
Plan text
Table
35. What is Gherkin?
35
Unambiguous executable
specification
Automated testing using
Cucumber
Document how the
system actually behaves
삼각 측량을 통해 케이스 별 시나리오/스텝 구성
36. What is Gherkin?
3636
Primary keywords
Feature
Background
Scenario
Given
When
Then
And
But
*
Scenario Outline
Examples
Secondary keywords
""" (Doc Strings)
| (Data Tables)
@ (Tags)
# (Comments)
Feature 제목
기능에 대한 설명
(사용자 스토리)
Test 실행과는 무관한 문서 요소
기능에 대한 시나리오로 다수의
step 으로 구성되며 테스트로 실행
39. Feature
소프트웨어 기능에 대한 상위 수준의 설명을 제공하고 관련
시나리오를 그룹화한다.
첫 번째 기본 키워드는 기능을 명시한다.
그 다음에는 기능을 설명하는 요약 정보를 명시한다.
테스트에 영향을 주지 않지만 Cucumber Report 에 사용된다.
파일명은 snake case 로 하는게 관례적 이다.
user_log_in.feature
Gherkin은 검증 시 다음의 하나는 필수적으로 명시되었는지 체크 한다.
Scenario
Background
Scenario Outline
3939
40. Scenario
4040
원하는 동작을 표현하기 위해 각 기능에 몇 가지 시나리오가 포함된다.
시나리오 이름만 사용하면 혼동을 일으킬 수 있다.
명확한 설명이 필요하고 문서화 되므로 명세화 해야 한다.
각 시나리오는 특정 상황에서 시스템이 어떻게 동작해야 하는지 보여주는 하나의
구체적인 예이다.
모든 시나리오에서 정의된 동작을 함께 추가하면 기능 자체의 예상 동작이 된다.
컨텍스트로 시작해서, 계속해서 어떤 행동을 실행하고, 마지막으로 결과가 기대했던
것인지 확인한다. 각각의 시나리오는 시스템이 해야 하는 것을 묘사하는 작은
이야기를 한다.
주요 패턴
시스템을 특정 상태로 만든다
상태를 수행한다
상태를 확인한다
각 시나리오는 타당해야 하며 다른 시나리오와 독립적으로 실행되어야 한다.
상태를 전이하는 시나리오는 지양하라.
42. Scenario
4242
Take Care with Your Naming Scenarios
시나리오 네이밍 정의는 놀랍게도 매우 중요하다.
테스트가 실패하면 무엇이 실패 했는지에 대한 헤드라인 정보를 제공하는 것이 실패
시나리오의 네이밍이다. 간결하고 표현력 있는 네이밍을 사용하면 모든 사람의 시간을
절약할 수 있다.
네이밍이 올바르다면 그것이 무엇을 하는지 알아내기 위해 내부 코드를 읽을 필요가
없다.
시스템이 진화함에 따라 이해 관계자는 기존 시나리오에서 예상되는 동작을 변경해 달
라는 요청을 자주하게 된다. 잘 정의된 시나리오 네이밍은 추가적인 단계 또는 단계를
수정하더라도 여전히 의미가 있다.
43. Steps - Given
시스템의 초기 컨텍스트인 시나리오의 장면을 가정하는 단계이다.
Cucumber가 Given 단계를 실행 할 때 작성 및 구성 또는 Test DB에
data 추가와 같은 잘 정의된 상태로 시스템을 구성한다.
사용자(또는 외부 시스템)가 시스템과 상호 작용하기 전에 시스템을
컨텍스트 상태로 전환하는 것이 목적이다.
4343
44. Steps – When
이벤트 실행 또는 설명하는 단계이다.
시나리오마다 하나의 단계만 수행하는 것이 좋다.
추가할 필요가 있다고 느끼면 시나리오를 여러 개로 나눠야 한다는
신호이다.
4444
45. Steps – Then
기대 결과 또는 결과를 설명하는 단계이다.
실제 결과를 기대 결과와 비교하기 위해 assertion 을 사용한다.
4545
46. Steps – And, But
Cucumber는 And, But 키워드 자체를 활용하지 않는다.
단지 이전 단계를 보조해 주는 역할을 한다.
즉, Step의 가독성을 주기 위해 도움을 주는 옵션이다.
4646
48. Steps – *
4848
Given, When, Then, And, But 이 장황하다고 여기는 사람도 있다.
(설마~ ㅋㅋ)
이때는 *(별표)를 이용할 수 있다.
단, 편의성은 있지만 가독성은 포기해야 한다.
49. Background
반복은 주의를 산만하게 하고, 각 Scenario 가 테스트하는
것에 대한 의도를 탁하게 만든다.
Background 섹션을 사용하여 모든 Scenario 의 공통적인
step 집합을 중복없이 컨텍스트화 할 수 있다.
Background 는 각 Scenario 시작 전에 실행되므로 첫 번째
Scenario 이전에 기술한다.
Feature 당 Background 는 하나여야 한다. 다른 Scenario
에 대해 다른 Background 가 필요하다면 Feature 를
분리해야 한다는 신호이다.
4949
52. Background
5252
Background Tip!
• 실제로 알아야 할 인수 정보가 아니라면 Background 사용을 지양하라.
• Background 를 간결하게 작성하고 눈에 띄게 만들어라.
• 사람들은 이를 주의 깊게 기억하는데 도움이 되어야 한다.
• 네 줄 이상이면 한 두 단계로 표현할 수 있는 방법을 찾아봐라.
• Scenario 가 많아 기반 화면을 초과하여 스크롤 될 경우 Background 에서 무슨 일이
일어났는지에 대한 전체 개요를 인지하기 어려워진다. Feature 를 분할하는 것에
대해 생각해 봐라.
53. Scenario Outline
다른 동일 Scenario 를 여러 번 실행하는 데 사용.
Scenario 를 복사하여 붙여 넣어 서로 다른 값을 사용하는
것은 중복이다.
Examples 섹션을 포함해야 한다.
표의 헤더를 참조하는 <> 구분 매개 변수를 사용
파라미터를 표의 값으로 대체
일반적인 데이터 표는 단일 Scenario 의 단계에 첨부할
데이터 묶음이다.
내부적으로 다수의 Scenario 로 실행함
5353
56. Scenario Outline
5656
MULTIPLE TABLES OF EXAMPLES (Scenario 도 가능)
Scenario Outline 의 수많은 예제 항목을 처리할 수 있다.
다양한 유형의 예제를 그룹화하여 가독성을 높일 수 있다.
57. Step Arguments
5757
Doc Strings
큰 크기의 텍스트를 단계 정의로 전달하는 데 유용
텍스트는 step 자체 라인에 세 개의 이중 인용 부호로 감싸서 표현
Step 정의에서 이 텍스트를 패턴에 반영시킬 필요는 없다. 이 값은 마지막
인수로 자동 전달된다.
58. Step Arguments
5858
String Transformations
String 이 아닌 다른 객체로 받으려는 경우
int, long, date, calendar 등 일반적인 객체 기본 지원
@Transform 어노테이션을 사용하여 직접 변환하는 경우
59. Step Arguments
5959
Data Tables
값 목록을 step 정의로 전달하는 데 유용
Doc Strings 와 마찬가지로 step 정의에 마지막 인수로 전달
Data Table API 제공
63. 63
How Many Examples Should I Use?
• 현실적인 주요 예제를 대상으로 하는 것이 가독성과 인수 조건에 부합한다.
다양하고 많은 예제로 검증하고자 하는 바램이 있겠으나 단위/통합 테스트에서 처리
하는 것이 이상적이다.
• 버그가 없다는 것을 인수 테스트에서 증명할 수 없다는 것을 기억하라.
증거의 부재는 부재의 증거가 아닌 무엇을 의도하고 목적을 어디에 두는 것이냐가
핵심이다!
• 가독성 이라는 것을 기억하고 너무 멀리가지 말고 항상 사람들과 정기적으로 읽고
피드백을 상호 교류하여 정련해야 한다.
64. Step Arguments
6464
@(Tags)
태그를 사용하여 Feature, Scenario 에 레이블을 부착할 수 있다
관련한 도메인 컨텍스트를 분류하여 탐색 및 가독성을 증진한다
Cucumber 실행 시에도 태그 단위로 제어할 수 있다
72. Write a Scenario
7272
Feature: 벌써 금요일 인가요?
모두가 금요일이 언제인지 알고 싶어합니다.
Scenario: 일요일은 금요일이 아니다.
Given 오늘은 일요일 이다.
When 오늘이 금요일 인지 묻는다.
Then 나는 "아니요." 라고 말합니다.
src/test/resources/hellocucumber/is_it_friday_yet.featu
re
99. Top 5 Cucumber Best Practices
9999
https://blog.codeship.com/cucumber-best-practices/
1. 선언적 Feature 를 작성하라.
scenario 는 사용자 관점에서 설명 될 수 있도록 작성한다.
링크를 클릭하고 양식 필드를 채우거나 코드 또는 CSS 선택 등이 포함된
실행
또는 내부 처리 관점의 설명이 아니다.
도메인 관점의 간결 명료한 선언적 feature 를 만들어야 한다.
100. Top 5 Cucumber Best Practices
100100
2. 내레이션으로 기술하라.
내레이션은 한 문장에서 기능이 무엇인지 설명한다.
이는 사용자 관점에서 도메인 이해 및 기능 자체가 필요한 역할을 설명하는
데
이점이 있다. 즉, 왜 처음에 이 기능을 구현 하는지를 이해 하는 데 중요
도움을
준다. 또한 기능에 대한 간략한 개요를 제공하므로 시나리오를 읽지 않고
다른
사람들이 대략적인 내용을 이해할 수 있다.
101. Top 5 Cucumber Best Practices
101101
3. 결합된 동작의 단일 Step 을 피하라.
결합 된 두 가지 동작이 포함 된 단일 단계가 발생하면 “And” 를 사용하여
두 단계로 나줘야 한다.
이는 한 단계 당 하나의 작업을 수행하는 것이 명확한 이해와 함께 단계
구현을
모듈화 하여 재사용 가능성이 높아진다.
102. Top 5 Cucumber Best Practices
102102
4. Step 정의를 재사용 하라.
Cucumber 에서는 Step 을 재사용 할 수 있다.
이는 다른 Step 의 동작을 확장하거나 여러 단계로 구성된 우수한 동작을
정의 할 때 편리하다.
이렇게 하면 유지 보수성이 향상되어 특정 동작을 변경해야하는 경우
단일 Step 정의만 변경하면 된다.
103. Top 5 Cucumber Best Practices
103103
5. Background 사용을 현명하게 사용하라.
모든 Scenario 를 시작할 때 동일한 Step 과정을 사용하는 경우
Background 를 배치하라.
단, 너무 길면 Scenario 가독성에 저해가 될 수 있으므로 너무 많은
Step 을 거치지 않도록 조심한다.
104. Write Great Cucumber Tests
104104
https://saucelabs.com/blog/write-great-cucumber-tests
105. Scenario and Step Definition Best Practices - Cucumber
105105
https://www.linkedin.com/pulse/scenario-step-definition-best-practices-
cucumber-dilshan-fernando
106. 15 EXPERT TIPS FOR USING CUCUMBER
106106
https://www.engineyard.com/blog/15-expert-tips-for-using-cucumber
107. 9 tips for improving Cucumber test readability
107107
https://www.foreach.be/blog/9-tips-improving-cucumber-test-readability
