Behavior Driven Development in Python
May 31, 2016
BDD (Behavior Driven Development) is agile methodology of testing, based on TDD (Test Driven Development). BDD tests are not focused on code, but on its effects. Tests are executed by the browser, so we can be sure, that test follows exact user steps. Tests are based on specification, so if test is finished with success, that program works in line with customer expectations.
When BEHAVE tests are usefull?
Primarily, if we want separate scenarios and code. Scenario layer can be created or edited by project manager as well as client. Programer and tester can prepare appropriate code layer.
Scenarios are made in Gherkin language, which is really similar to human language, so they are clear to all people. They can be modified and expanded even by non technical people.
Behave tests are integration tests: they can find errors with communication between modules of application, which one of them was tested singly, but they wasn’t tested together before.
Unit testing does not detect compatibility with browsers, and bugs due to the different work of the browsers. Behave tests can be run with different browsers, with different window sizes and parameters.
Full packet of scenarios can be run after some changes in source code of the page, tweaking visual layer to make sure that user experience is still consistent and to catch all potentials regressions.
Behave is an easy to run environment. Tests can be prepared quickly, so the cost of starting the process is low. When first tests are already running, next can be created. Finished tests can be multiply used not only in the developement process, but also in the later use of the application. If you want to change the application behaviour later - tests can be easily adjusted.
Two ways of preparing tests
First way is to create tests based on user scenarios provided by client. According to principle BDD, test should be created before main source code. Scenarios are implemented according to test environment and tests are created before or parallel to creating software. At each phase of development, finished feature has coverage in corresponding steps of test case scenario.
Second way is creating all tests when software is completed. Tests can help find hidden bugs, before final project deployment or enhance the quality of working application . Client may receive test scenarios, and tests results.
What can be tested by Behave tests?
In Behave we can test application in many different ways. It’s may be action tests, like user paths, flows by the structure of application or different process, which can be verified only by integration tests. We can also test appearance of application such as: correct display of content or graphic, forms filling, alerts, validation messages etc etc..
How it works?
Every scenario has template: initialization, setting up start parameters, running user steps, checking expected results. Every line of a scenario calls the corresponding functions. Of all steps are executed and expected results are correct - test passed, in other cases - test failed.
Tester/client/project manager can compose scenarios based on predefined functions prepared by programmer. Scenarios can also contains data as numbers, usernames, passwords or search queries. For many data sets they can create tables with this data for each scenario, and that scenario is running multiple times, for any lines of data.
Behave uses popular test environment: Selenium.
Lets get started!
Structure of scenario:
Feature: Title (one line describing the story/feature)
As a [role]
I want [feature]
So that [benefit]
Scenario: Title1 (for Behaviour 1)
Given [context or setup]
And [some more context]...
When [event occurs]
Then [expected outcome]
And [another outcome]...
Scenario: Title2 (for Behaviour 2)
...
Simple scenario:
Feature: Simple page tests
Scenario: check a title
Given page address
When page is loaded
Then I see title
more complicated scenario:
Scenario: change of quantity in cart
Given page address
When I login
and I add product to cart
and I set quantity to 3
Then I see this product in cart
and I see 3 products in cart
and I see correct price for 3 products
When I set quantity to 8
Then I see this product in cart
and I see 8 products in cart
and I see correct price for 8 products
scenario outlines:
Scenario Outline: add one product in specified size to cart
Given page address
When I login
and cart is empty
and I search product with sizes by name: <name>
and I choose specified size: <size>
and I add product to cart
Then I see product: <name> with size: <size> in cart
Examples:
| name | size |
| Asics GEL-1170 | 42 |
| Karrimor Run Shorts Mens | S |
| Running Socks Mens | 41-42 |
but sometimes outlines can be simplier, because inside logic of code is more complicated
Scenario: register random users
Given registation page
When I register 50 random users from selected countries
by real-data users generator
Then I see new 50 users in admin panel
Scenario: add many product to the cart
Given internet shop page
When cart is empty
And I add 25 random products from random categories with random quantity beetwen 1 and 100
Then I see 25 products in cart
And I see correct quantity of each product in cart
And I see correct price for quantity of each product
And I see correct total quantity of products in cart
And I see correct total price of each product
When I order it
Then I see correct weight of all products
And I get correct kind of package
And I see correct price for weight of package
And I see correct address data on order
When I confirm order
Then I receive order confirmation
How much time tester will spend on this two scenarios, if he/she wants to execute them manually? In Behave - it can be done by one command. Many times, after every small upgrade of your web page, or after filling shop by new products. After every pass - you receive summary report. It’s a power of automation. On the other hand, how much time tester can spend or writing tests in behave? This is simple and effective way to increase quality of your software in cost effective way.
Summary:
Behave tests
- gives high added value: it tests integrally interface of application from user perspective
- separate tests scenarios and code
- are clear, there is no need create other documentation, even more! They could be documentation of the system.
- scenario language is easy, can be created and developed by non-technical people separately or with developers.
- scenarios and reports are eligible - client can be sure, which functionalities are tested
- barrier to entry is low
- cost is low (because time is short)
Comments
comments powered by Disqus