Exploring your first cucumber project
This is more of an informative part of the tutorial. If you don't feel like reading, you can skip to part 5: Exercises
Contents
Feature files
Let's start off by having a look at the feature files. Open ./features/example.feature
and you should see the following:
- Tags
@exmaple
- a Feature
Feature: Example Feature
- A description of the feature
When I want (...) the tests below
- Multiple sceanrios
Scenario: example01 - Spritecloud search
- Steps
Given the user navigates to "blog"
Tags
A tag is used to be able to filter certain feature or scenario's when running your script in Cucumber. Open 'CMD', go to your project folder and try it out:
bundle exec cucumber -t @example # Will run the complete Feature: Example bundle exec cucumber -t @example01 # Will only run the first Scenario bundle exec cucumber -t @example -t ~@example01 # Will run all scenario's in the Example feature, except for the first one.
Feature, Scenario, Steps
Features
A feature represents a major functionality of a website. This could be a single page or a functionality over multiple pages. Wether something actually is a separate feature is left to your own judgement. You don't want too much scenario's in 1 feature file, but also, you don't want too little. For example:
A product detail page
This could be a feature on itself with all the functionalities this page could have. Think of:
- Viewing the product image
- Adding an item to your basket
- Folding open a detailed description of the product.
Ordering a product
This is not a separate page, but more a flow that a user goes trough. Even though a part of this Feature is the product detail page, the complete flow of ordering a product goes trough multiple functionalities. In the end, on a feature like this, you would want to test specific order types, for example:
- Ordering 1 product with shipping cost
- Ordering multiple products, going over the free shipping threshold
- Ordering a product with a discount code
Scenario's
In a scenario, you will confirm 1 functionality. An often made mistake is to confirm multiple functionalities in 1 scenario. On large projects, this will ruin the maintainability of your test automation suite. In example.feature
you will see that every scenario just confirms 1 thing.
Steps
A step is the part that will actually execute your Selenium code. More about this in the next heading: Step Definitions
Step definitions
Organising your files
If you go to the folder ./features/step_definitions/
You will see 3 files:
precondition_steps.rb
contains all the "Given ..." stepsinteraction_steps.rb
contains all the "When ..." stepsvalidation_steps.rb
contains all the "Then ..." steps
This is an example of how you can manage your step definitions orderly. In the end, just like features, it's to the TA engineer how they feel is the most organised way. For example, you can create a new file for every feature, or you could even write everything into 1 big step definition file (not recommended).
The step definition
Open ./features/step_definitions/interactions_steps.rb
and have a look at line number 28: "the user clicks on link ..."
When(/^the user clicks on link "(.*?)"$/) do |url| # Search for the element that includes the expected text browser.wait( :like => { :element => :a, :attribute => :href, :include => url } ).click end
Find out more about how to define a step on Cucumber Step definitions. In this case a wildcard is used in the step definition (.*?)
. This wildcard is then stored in a variable url
.
Then bewteen "When" and "end", there is code that will interact with the browser. What it's basically saying is 'Look for an element <a href="url">
where url
is whatever was filled into the step. More about interacting with the browser in the next chapter of this tutorial.
config.yml
The file ./config/config.yml
is used to re-used defined variables. Mostly used to store user credentials or to translate a page name into a page URL. Also commonly used to define different data between different test environments. For example, the URL to the test environment is different than the one to the production environment.
Lapis Lazuli has build in functions that loads these variables:
env('pages.root')
will load the root configuration value from the selected environment, E.G. production -> pages -> root = https://spritecloud.comconfig('user.default-user.username'
will load a configuration value independent from the selected environment, so users -> default-user -> username = test
Other advanced files
env.rb
When running cucumber in the console, ./features/support/env.rb
is the first file that is loaded. It will start Lapis Lazuli and load all the dependent gems. Also, in this file you can add repeating scripts, that should be ran before or after everything feature, scenario or step. See Cucumber Hooks for more information.
functions.rb
In this file we've defined multiple repeating functions. It's created this way to prevent too much code in the step_definitions. Also, you don't want to repeat yourself. In the folder ./features/support/
you can add any .rb
file and it will be loaded before your cucumber feature files are executed.
Gemfile
Finally, there is the Gemfile, here you can add any Gems that you're using for your project. For example, sometimes you want to directly connect to a SOAP back-end environment, for this there is a Gem. Simply add the gem to your Gemfile and you can start using the Gems functionalities in your step definitions.