Transcripted Summary
In the first chapter we'll be going over what exactly is BDD and how it connects to Cucumber.
Let's dive right in.
BDD stands for behavior-driven development, and it's an example-based method for developing software.
It includes many different collaborative activities and techniques performed by stakeholders, namely the product owner, the tester, and the developer, often referred to as the Three Amigos.
One of the major activities is having the Three Amigos meet to discuss and document examples of how a system should act and be used. These examples describe how the software is intended to behave, often illustrating a particular business rule or requirement.
It's important to note that these examples do not outline how a system, or its features should be implemented, only how it should behave.
The end result of discussing and documenting these examples is that all parties should come to a mutual understanding of how the feature will behave in various scenarios, and by extension, how the system itself should work.
An important point to note is that BDD is not solely a testing technique.
Much like test-driven development, it's a process of approaching your design and forcing you to think about the desired outcome before you code.
Test cases and eventually automated tests should be a byproduct of following a BDD approach and having great properly structured examples.
Let's talk a bit about BDD's value.
The major goals of BDD are to narrow the communication gaps among team members, foster a better understanding of the customer's needs, and promote continuous communication throughout the software development process.
From the very beginning of developing software through to the end, BDD involves the collaboration of all team members to get an understanding of the needs of a system.
Through this continuous collaboration, we get quite a few benefits. We get the entire team speaking the same domain language, we see silos being broken down, and there is a shared understanding of what needs to be done. This is extremely valuable, especially in saving time and eventually money.
Another added benefit is the examples that are generated from team meetings can as executable artifacts that drive test automation, and we will get to see this firsthand in the future chapters as we develop our own examples and create automation from them.
Okay, so we've learned a few new terms that I want to go over because they'll definitely come up in future lessons.
Three Amigos refers to the main stakeholders in the software development process: product owner, tester, and developer.
Example-based is an approach to software development that leverages the creation of examples to drive discussion, understanding, development, and testing.
An example is a description of how the software is intended to behave, often illustrating a particular business rule or requirement.
Gherkin is a special syntax that should be used when developing examples. This is designed in a way for anyone to understand the behavior of a feature.
