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:
more complicated scenario:
but sometimes outlines can be simplier, because inside logic of code is more complicated
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.
- 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)