Using Behaviour driven development with Gherkin, we can bring the system requirements into the heart of the project. We make them a living part of the development process, accessible by all, driving the code, and yet still written in a human readable format. Even better, we can link these requirements to automation tests, so that a build will execute the tests and show you the status of the application against the requirements. The report will show you how many requirements have been developed, how many of them are tested and working and what is still to-do.
How do we get there? What magic do we need to work to get to this utopia?
Collaboratively write the requirements in feature files, in simple GIVEN, WHEN, THEN format.
Create some Step Definitions (tests scripts) that will link each feature file statement through to the automated tests. The automated tests can be Integration and API tests, or Selenium front end tests.
For the Selenium Automation, use a model to create the actions for your test steps. For example, create page objects; a place to define the test step actions that make them easily maintainable and more robust.
Add them to you Continuous Integration pipeline. Every time you trigger a build, you’ll get a comprehensive status report against the requirements.
What are these files and objects?
This file is where we define and discuss a feature. This will contain any questions for follow up, rules for implementation and our user stories in human readable Gherkin format: "GIVEN, WHEN, THEN".
For each page on your website you'll create a page object class. It will contain any test methods (steps /actions) that you might do on that page such as identify a form field, enter data, click links and check the page title. These are not written as tests, but as actions /steps to complete.
This keeps all of the coded automation steps in one easy to find place which improves maintainability, reliability and visibility.
See more on the Page Object Model
This is the glue that sticks the readable requirements to the coded test steps. This is where you take the “GIVEN I am logged in” statement, and link it to a class that will then call the login test method. It’s also where you can add your assertions for your expected results.
Each class in this Step Definitions file links backwards to the feature file and forwards to a class that contains the test method to execute.
We have one more file that we use for BDD called RunCukes. This is a test class that is used to trigger running our BBD tests. This file contains settings that define where the features and tests are and any @before and @after conditions that we don't want to report on (starting up a browser and navigating to the site, closing a browser). We can also define here which browser we want to use, what URL we want to go to, and any plugins we want to use for reporting.