| Foreword |
|
xiii | |
| Preface |
|
xv | |
| Acknowledgments |
|
xviii | |
| About This book |
|
xx | |
| About The Cover |
|
xxiii | |
| 1 Introduction to specification by example and Gherkin 1 |
|
|
1.1 What's a specification? |
|
|
4 | (1) |
|
1.2 Why do teams need specifications? |
|
|
4 | (4) |
|
Defining acceptance criteria in specifications |
|
|
5 | (1) |
|
Building a ubiquitous language into specifications |
|
|
6 | (2) |
|
1.3 Common specification pitfalls |
|
|
8 | (3) |
|
|
|
8 | (1) |
|
|
|
8 | (1) |
|
|
|
9 | (1) |
|
|
|
10 | (1) |
|
|
|
10 | (1) |
|
1.4 Meet specification by example and Gherkin |
|
|
11 | (3) |
|
|
|
13 | (1) |
|
1.5 Having conversations that identify business needs |
|
|
14 | (5) |
|
Deriving scope from goals |
|
|
15 | (1) |
|
Illustrating requirements with examples |
|
|
16 | (2) |
|
Specifying collaboratively |
|
|
18 | (1) |
|
1.6 Long-term benefits of automating conversations |
|
|
19 | (3) |
|
Automating tests based on examples |
|
|
19 | (2) |
|
|
|
21 | (1) |
|
|
|
21 | (1) |
|
1.7 Capturing conversations as executable specifications |
|
|
22 | (3) |
|
1.8 Making software that matters |
|
|
25 | (2) |
|
|
|
27 | (2) |
| Part 1: Writing Executable Specifications With Examples |
|
29 | (142) |
|
2 The specification layer and the automation layer |
|
|
31 | (23) |
|
2.1 The layers of executable specifications |
|
|
32 | (6) |
|
|
|
33 | (1) |
|
|
|
34 | (4) |
|
2.2 Writing your first Gherkin scenario |
|
|
38 | (5) |
|
|
|
38 | (1) |
|
|
|
39 | (1) |
|
|
|
40 | (2) |
|
|
|
42 | (1) |
|
|
|
42 | (1) |
|
2.3 Understanding the structure of steps and scenarios |
|
|
43 | (2) |
|
2.4 Testing different outcomes |
|
|
45 | (2) |
|
2.5 How the automation and specification layers interact |
|
|
47 | (4) |
|
|
|
47 | (1) |
|
Matching steps with step definitions |
|
|
48 | (3) |
|
2.6 Finishing the Gherkin crash course |
|
|
51 | (1) |
|
|
|
52 | (1) |
|
|
|
53 | (1) |
|
3 Mastering the Given-When-Then template |
|
|
54 | (26) |
|
3.1 Choosing the right style for your Gherkin scenarios |
|
|
55 | (9) |
|
Doing outside-in development with Gherkin |
|
|
56 | (5) |
|
|
|
61 | (1) |
|
Favor specifying intentions and outcomes over the user interface |
|
|
62 | (2) |
|
3.2 Composing Gherkin scenarios |
|
|
64 | (10) |
|
|
|
64 | (1) |
|
Using only one When per scenario |
|
|
65 | (2) |
|
Specifying prerequisites with Givens |
|
|
67 | (4) |
|
Choosing the right abstraction level |
|
|
71 | (3) |
|
3.3 Telling Gherkin stories with impact |
|
|
74 | (3) |
|
Writing warm-up narratives |
|
|
74 | (1) |
|
Vetting acceptance criteria with examples |
|
|
75 | (1) |
|
Exploring contexts by questioning |
|
|
|
|
|
75 | (1) |
|
Exploring outcomes by questioning Thens |
|
|
76 | (1) |
|
|
|
77 | (2) |
|
|
|
79 | (1) |
|
4 The basics of scenario outlines |
|
|
80 | (17) |
|
4.1 Example shopping application |
|
|
81 | (1) |
|
4.2 Using scenario outlines |
|
|
82 | (4) |
|
Spotting redundancies in Gherkin scenarios |
|
|
82 | (2) |
|
Refactoring redundant scenarios with scenario outlines |
|
|
84 | (2) |
|
4.3 The structure of a scenario outline |
|
|
86 | (3) |
|
|
|
86 | (1) |
|
|
|
87 | (1) |
|
The Scenario Outline keyword |
|
|
88 | (1) |
|
4.4 Advantages of scenario outlines |
|
|
89 | (1) |
|
|
|
89 | (1) |
|
Feature files organized by high-level business rules |
|
|
89 | (1) |
|
4.5 Growing and maintaining scenario outlines |
|
|
90 | (5) |
|
4.6 Disadvantages of scenario outlines |
|
|
95 | (1) |
|
|
|
95 | (2) |
|
5 Choosing examples for scenario outlines |
|
|
97 | (26) |
|
5.1 Example shopping application |
|
|
99 | (1) |
|
5.2 Writing outside-in scenario outlines |
|
|
99 | (3) |
|
Collecting examples for outside-in scenario outlines |
|
|
100 | (1) |
|
Writing outside-in scenario outlines from collected examples |
|
|
101 | (1) |
|
5.3 Finding key examples for scenario outlines |
|
|
102 | (12) |
|
|
|
104 | (2) |
|
|
|
106 | (1) |
|
|
|
107 | (4) |
|
|
|
111 | (3) |
|
5.4 Avoiding scenario outline anti-patterns |
|
|
114 | (7) |
|
|
|
114 | (1) |
|
Simple combinatorial outcomes |
|
|
114 | (3) |
|
|
|
117 | (2) |
|
|
|
119 | (2) |
|
|
|
121 | (1) |
|
|
|
122 | (1) |
|
6 The life cycle of executable specifications |
|
|
123 | (25) |
|
6.1 End-to-end overview of the process |
|
|
126 | (1) |
|
6.2 Understanding business goals |
|
|
127 | (3) |
|
6.3 Analyzing requirements with examples |
|
|
130 | (7) |
|
Conveying requirements as user stories |
|
|
130 | (3) |
|
|
|
133 | (2) |
|
Refining user stories with examples |
|
|
135 | (2) |
|
6.4 Deriving scenarios from examples |
|
|
137 | (2) |
|
|
|
139 | (2) |
|
6.6 Iterating specifications over time |
|
|
141 | (6) |
|
Validating the specification suite |
|
|
141 | (3) |
|
Evolving the documentation system |
|
|
144 | (3) |
|
|
|
147 | (1) |
|
|
|
148 | (23) |
|
7.1 Living documentation in action |
|
|
150 | (3) |
|
7.2 Writing documentation |
|
|
153 | (1) |
|
7.3 Defining important domain concepts |
|
|
154 | (6) |
|
Writing lexical definitions |
|
|
154 | (2) |
|
Writing illustrative definitions |
|
|
156 | (2) |
|
|
|
158 | (1) |
|
Naming important domain concepts |
|
|
158 | (2) |
|
7.4 Documenting decisions using briefs |
|
|
160 | (1) |
|
Using warning notes to highlight problematic areas |
|
|
160 | (1) |
|
Using context notes to deepen the business context |
|
|
160 | (1) |
|
Using maintenance notes for internal purposes |
|
|
161 | (1) |
|
7.5 High-level overview of the documentation process |
|
|
161 | (2) |
|
7.6 Who creates living documentation? |
|
|
163 | (3) |
|
Creating documentation through all-team specification workshops |
|
|
164 | (1) |
|
Creating documentation through Three Amigos meetings |
|
|
164 | (1) |
|
Creating documentation through individual people |
|
|
165 | (1) |
|
7.7 Choosing the right audience for living documentation |
|
|
166 | (3) |
|
Who's a minimally qualified reader? |
|
|
166 | (1) |
|
Finding the perfect MQR in an organization |
|
|
167 | (2) |
|
|
|
169 | (1) |
|
|
|
169 | (2) |
| Part 2: Managing Specification Suites |
|
171 | (80) |
|
8 Organizing scenarios into a specification suite |
|
|
173 | (22) |
|
8.1 Is organizing scenarios by features a good idea? |
|
|
175 | (1) |
|
8.2 Organizing scenarios by user stories |
|
|
176 | (10) |
|
Introducing the Ability keyword |
|
|
177 | (5) |
|
Understanding the structure of user stories |
|
|
182 | (1) |
|
Analyzing the relationship between user stories and executable specifications |
|
|
183 | (1) |
|
Iterative dangers of organizing scenarios by user stories |
|
|
184 | (2) |
|
8.3 What about nonfunctional requirements? |
|
|
186 | (7) |
|
Dealing with nonfunctional requirements according to SBE |
|
|
187 | (1) |
|
Can Gherkin specify nonfunctional requirements? |
|
|
188 | (1) |
|
Introducing the Business Need keyword |
|
|
189 | (1) |
|
Using the Business Need keyword to identify new stakeholders |
|
|
190 | (3) |
|
|
|
193 | (1) |
|
|
|
194 | (1) |
|
9 Refactoring features into abilities and business needs |
|
|
195 | (18) |
|
9.1 Analyzing user stories: a practical example |
|
|
196 | (1) |
|
9.2 Refactoring features into abilities |
|
|
196 | (7) |
|
Deriving new scenarios from user stories |
|
|
197 | (1) |
|
Starting with simple features |
|
|
197 | (1) |
|
Adding scenarios over time |
|
|
198 | (2) |
|
Splitting huge features into small abilities |
|
|
200 | (3) |
|
9.3 Recognizing and refactoring business needs |
|
|
203 | (9) |
|
Adding functional scenarios to business needs |
|
|
204 | (3) |
|
Identifying new stakeholders with business needs |
|
|
207 | (1) |
|
Refactoring functional scenarios in business needs into individual abilities |
|
|
208 | (4) |
|
|
|
212 | (1) |
|
10 Building a domain-driven specification suite |
|
|
213 | (21) |
|
10.1 Distilling business domains from a ubiquitous language |
|
|
215 | (6) |
|
Spotting different domains in your scenarios |
|
|
216 | (2) |
|
Distilling the core domain from scenarios |
|
|
218 | (1) |
|
Distilling subdomains accompanying the core domain |
|
|
219 | (2) |
|
10.2 Creating a domain model from distilled domains |
|
|
221 | (3) |
|
The domain model and the specification suite |
|
|
221 | (1) |
|
Why are good domain models important? |
|
|
222 | (2) |
|
What makes a good domain model in software? |
|
|
224 | (1) |
|
10.3 Building a domain-driven specification suite in practice |
|
|
224 | (7) |
|
Distilling subdomains from unequivocal scenarios |
|
|
225 | (1) |
|
Distilling subdomains from mixed scenarios |
|
|
226 | (2) |
|
Distilling subdomains from other scenarios |
|
|
228 | (2) |
|
Creating a specification suite from distilled domains |
|
|
230 | (1) |
|
10.4 Answers to exercises |
|
|
231 | (2) |
|
|
|
233 | (1) |
|
11 Managing large projects with bounded contexts |
|
|
234 | (17) |
|
11.1 Analyzing domain concepts in context |
|
|
235 | (6) |
|
|
|
236 | (1) |
|
Dealing with false cognates |
|
|
237 | (2) |
|
Spotting duplicate concepts |
|
|
239 | (2) |
|
11.2 Modeling specification suites as bounded contexts |
|
|
241 | (7) |
|
Understanding bounded contexts |
|
|
241 | (1) |
|
Splitting a large specification suite into multiple bounded contexts |
|
|
242 | (3) |
|
Managing bounded contexts with context maps |
|
|
245 | (1) |
|
|
|
246 | (2) |
|
11.3 Fitting DDD into an SBE process |
|
|
248 | (1) |
|
|
|
249 | (2) |
| Appendix: Executing Specifications With Cucumber |
|
251 | (18) |
| Index |
|
269 | |
Lisainfo e-raamatute kohta