The simplicity thesis
The simplicity thesis
My thoughts on automation engineering
• The Given/When/Then convention is central to the notion of BDD. It just connects the human concept of cause and effect, to the software concept of input/process/output. When using a formal language like Gherkin for describing the software‘s behavior, it is possible to use a tool that interprets the intent of the requirement and then drives the system under test to ensure that the requirement works as expected.
Given When Then as state transition
• Given: put the system in a known state to be explored
• When: describe the key action or stimulus to that system
• Then: observe outcomes
• If we observe we will see that Given When Then is nothing more than a description of a state transition and that the sum of all Given When Then is nothing more than a finite state machine. From a engineering point of view, it should be possible to describe any feature as a state transition table. Meaning so, we are not only able to predict how many scenarios our specification should have, but we should also be able to optimize the specification finding the machine with the minimum number of states that perform the same function.
Gherkin
• Gherkin is the language that Cucumber understands. It is a Business Readable, Domain Specific Language that lets you describe software’s behavior without detailing how that behavior is implemented.
• Gherkin serves two purposes – documentation and automated tests. The third is a bonus feature – when it yells in red it’s talking to you, telling you what code you should write :-)
Example of a feature described in Gherkin language:
Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses
Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |
Given When Then
Readable, Domain Specific Language
• The argued benefit of using a domain specific language is that the language we use affects the way we think, and so if we use a language closer to the way humans think about problems, we will get better thought processes or concepts and therefore better results.