Cucumber’s logic
To properly organize your tests in the Cucumber framework, it’s important to understand its logic and where each element should be located. This applies regardless of the specific programming language being used.
First and foremost, you should start with the business logic. This is important even if you don’t want to use Cucumber or even automate your tests at all. If you want to use Cucumber, then the business logic of your tests should be described in the feature files. These files should be written in Gherkin syntax, which is a language designed to be easily readable and understandable by both technical and non-technical stakeholders. In the feature files, you should describe the specific scenarios that you want to test, along with any relevant background information.
It is not only important what should be in feature files, but also what should not be there. You should not try to describe the detailed implementation of each test scenario. This is not the purpose of this layer of tests.
Let us take a look at the general organization of tests in the Cucumber framework.
Feature files:
- test logic in Scenarios
- test data in Examples
Runner part (often called Hook):
- here the automation engine is initialized
- this part is responsible for collecting results (e.g. screenshots, logs etc.)
- no test data
- no GUI specific code
- no test logic
Step definitions (Glue code):
- Actions in “Given” and “When” steps
- Assertions in “Then” steps
- it uses only Page Objects methods, not the WebUi automation engine directly
- no direct driver calls
Page Objects representation (including Screenplay Pattern):
- no test data
- no test logic
- no assertions
- only page specific code
Let us summarize it in the following table.
Nothing but glue executes Page Object methods. Nothing but glue takes test data from feature files. The Runner is responsible only for starting and stopping the engine and collecting results. Nothing but feature files have all test data.
In this way, if we want to change our engine from Selenium to Playwright (or vice versa), then we only need to change one layer related to Page Objects and a small part of the Runner. We can completely change our test data within the defined steps, and no changes in other layers should be required. Finally, we can get rid of Cucumber at all, and our tests should still work. We can also keep the features layer and implement all tests in another programming language. John Ferguson Smart suggests one more example: “Could we replace the whole implementation of the application without touching the Gherkin scenarios? One team I worked with has recently rewrote an entire application in a different technology stack, without changing a line of Gherkin.”
All this is possible thanks to keeping the order in the code and in the mind. By following this logical organization of tests, you’ll be able to keep your code clean and maintainable, and you’ll be able to easily update your tests as your application evolves. Additionally, this approach makes it easy to collaborate with other members of your team, since each person can focus on a specific area of the codebase.
The story was originally created by me, but it may contain parts that were created with AI assistance. My original text has been corrected and partially rephrased by Chat Generative Pre-trained Transformer to improve the language.
