Gherkin /BDD intro
Download as PPTX, PDF6 likes4,797 views
Gherkin is a business readable language used to write automated acceptance tests in a format called scenarios. Scenarios use keywords like Given, When, Then to describe a system's behavior in a way that both technical and non-technical team members can understand. Cucumber is a tool that reads Gherkin files and runs acceptance tests. The Gherkin syntax and Cucumber tool support a behavior-driven development process where tests are written before code using a collaborative approach between developers, testers, and business stakeholders.
Gherkin /BDD intro
- 2. 1) Walk thro AGENDAGherkin Refresher • What • Why • Syntax How it fits into BDD Practical Example
- 4. WHAT IS GHERKIN? Officially … Gherkin is the language that Cucumber understands. It is a Business Readable, Domain Specific Language, that lets you describe software’s behaviour without detailing how that behaviour is implemented.
- 5. WHAT IS GHERKIN? Unofficially it’s … Gherkin is a business readable language used to express the system’s behaviour. The language can be understood by an automation tool called Cucumber It consists of 10 key words
- 6. WHAT IS GHERKIN? Acceptance test written in Gherkin
- 7. WHAT IS GHERKIN? • Given • When • Then • And • But • Scenario • Feature • Background • Scenario Outline • Examples
- 8. WHY USE GHERKIN? 1) Gherkin allows us to document acceptance tests in a language devs, QA, BAs & the business can understand. It allows the 3 Amigos to collaborate and understand tests in a common language.
- 9. WHY USE GHERKIN? 2) Gherkin links our acceptance tests (GIVEN/WHEN/THEN) directly to automated tests. This means if we change an acceptance test – the developers underlying tests should fail. We can be confident the system matches the specification. As part of BDD we want to write many automated tests to improve our confidence in the product. We want these tests to be understandable + valuable.
- 10. BASIC SYNTAX Given = system in known state When = key action Then = observable outcome Scenario = Title of the acceptance test (e.g. “the one where”)
- 11. BASIC SYNTAX And = used instead of multiple Givens / for complicated scenarios
- 12. BASIC SYNTAX But = used in association with Then
- 14. ADVANCED SYNTAX Feature = title for the feature Feature file = a file that contains AC’s and Scenarios usually stored in GitHub
- 15. ADVANCED SYNTAX Background = set the context for all scenarios
- 16. ADVANCED SYNTAX Scenario Outline / Examples = used to combine a set of similar scenarios Use tags to identify test suites/group scenarios
- 17. BDD IN A NUTSHELL
- 18. 1) Developer writes the test before the code 2) It’s behavioural/high level tests (e.g. not unit tests) BASIC PRINCIPLES
- 19. BDD PROCESS Step definition = written by the devs for each step
- 20. WHY USE BDD? 1. Ensures automated code coverage 2. Valuable tests
- 21. Cucumber Notes Cucumber is designed to build bridges between the technical and non-technical members of a software team by the use of automated acceptance testing. They are sometimes called executable specifications. It’s vitally important that feature tests can be easily read and understood by any member of the team. Developers and stakeholders (POs / BAs / etc) work together with QAs and developers to create automated tests that reflect the outcomes the stakeholders want. During this process the team will develop a ubiquitous language to describe things and actions referenced in the service such as “customers”, “service agents”, “payments out” or “account balance”. Feature tests are different to unit tests which are written by developers to ensure that each component they build functions as expected from a basic functionality point of view. Feature tests can do this from a business point of view but they can also span multiple components. Tests are written first before any code so will they fail when originally written as there is no code to test at that point! This is called Test Driven Development or Outside-In Development. Tests are written as scenarios which are examples of how we want to use the system (n.b. this includes showing us appropriate errors if we or the system do something wrong). Cucumber can produce an HTML file describing all the tests that can be executed for a system. This can be used to automatically created living documentation of how the system will function. Cucumber tests are written in a language called Gherkin. They consist of: ● Features: Groups of tests ● Tags: Another way to group tests ● Scenarios: Individual tests ● Steps: The component parts of each test Comments in Gherkin must take up a whole line of text and must start with a # (hash). Developers will create step definition code that will map from the humanly readable steps to the code that can interface with the system. Cucumber can be run by the developers on the command line before they submit their code to git and also as part of a continuous integration test service such as Jenkins. The output from Jenkins can be an HTML page that can be read by anyone in the team. FURTHER READING
- 23. KEYWORDS QUIZ – PART 1 1. Gherkin 2. Steps 3. Cucumber 4. Scenarios 5. Acceptance criteria C) A language used to write acceptance tests. It consists of 10 key words B) A tool used for testing software E) Consist of steps + the scenario title. These are your acceptance tests D) Bullet pointed list of rules. These can be tested using scenarios A) These put the system in a state, specify the action & the outcome. GIVEN/WHEN/THEN/AND/BUT
- 24. 6. Feature file 7. BDD 8. Step definition 9. Github I) A document/file that contains the user story, acceptance criteria & scenarios. It’s saved as .feature J) Behaviour driven development. Write the expected behaviour & tests first – test fails – then write the code F) Written by the developer. Every step has one of these H) Allow us to write acceptance tests in a common language & for these tests to be automated with Cucumber 10. Reasons to use Gherkin G) A repository used to store code + feature files. Think of it like a shared drive KEYWORDS QUIZ – PART 2
- 26. 1) How many people know what Gherkin is? 2) How many people use Gherkin on their project? 3) How comfortable are people with terms like Gherkin/Cucumber/BDD/Scenario Outline/Step Definitions/Github/Feature Files? STARTER FOR 10
Editor's Notes
- #2: Refreshed version talk given in Stockport Gherkin & BDD for BAs
- #3: Gherkin Refresher: what, why, syntax BDD. Feature files Example from BOMAD
- #5: Basic & advanced syntax Example from BOMAS
- #7: Business a readable language for BA's to express the system's expected behaviour.
- #8: Business a readable language for BA's to express the system's expected behaviour.
- #9: Easy to understand format for Acceptance Tests Helps bridge a gap between requirements and tests
- #10: The specification is executable. The tests & code & Acs are in sync. It means the specification becomes a living document & the source of truth
- #11: GIVEN puts the system in a known state. These are basically preconditions. e.g. "GIVEN user is logged in” WHEN a key action THEN observable outcome
- #12: AND can be used instead of multiple GIVENs / when / then
- #13: AND can be used instead of multiple GIVENs
- #14: 6 words
- #15: A feature is something that your software does (or should do), and generally corresponds to a user story and a way to tell when it’s finished and that it works. Acs = what you want the system to do Scenarios = what you want to be tested. This tests instances of the rules
- #16: Above a set of scenarios you can write a background. The background allows you to add context to all the scenarios. The background is run before each of your scenarios.
- #17: A Scenario Outline is a way that you can combine a set of similar scenarios using tables. For example: Tag JIRA tickets Tag e.g. JS
- #19: Write a test. That means they’ll be a failing test. It also means each piece of functionality will have test coverage BDD tests are behavioural. Testing micro level code … testing behaviour of the system from a user’s perspective
- #20: Step definitions allow the developer to run the scenarios against the system. They map the business-readable language of gherkin into code. If a BA changes a step, it will probably result in the test failing. TDD = tests are at a unit level. Still write them first BDD = high level tests of behaviour Step definition translate Gherkin into Java code Why? Ensures code coverage and regular releases. Means tests are understandable and test behaviour rather than the code
- #21: Reduces manual testing. Can do regular releases Means tests are understandable and test behaviour rather than the code
- #24: 1 C 2 A 3 B 4 E 5 D
- #25: 6 I 7 J 8 F 9 G 10 H
- #26: General tips for scenarios: Do a few tests Testing triangle Focus on the happy path Don’t write the manual ones
- #27: Basic & advanced syntax Example from BOMAS