Often the solution for automated testing becomes quite complex, for writing tests and all auxiliary code required programming skills, and sometimes not even an entry-level, and a little taller. At the same time, there is a tendency to simplify working with autotest. This is achieved by adding various wizards, the creation of certain approaches and engines that implement this approach. In particular, the so-called popular keyword-driven approach, where the test is a sequence of key words, structured in tables. But there’s more catchy approach in which the tests are presented in the form of conventional instructions written in plain text, for which there is a certain level implementation of the code. Ruby’s is a slider called Cucumber.
So, let’s say we have a test case, described as follows:
Immediately it is worth noting that the script is taken from the ceiling. We consider a "spherical application in vacuum", which has the functionality to zaloginivaniya, as well as have some search functionality. Suppose, in Ruby this test is implemented as follows:
1 app.login
2 app.click_button "Search"
3 assert app.search_screen_displayed? , "No search screen available"
We proceed from the assumption that all needed to run this script, the functional we have. Here and so compact you can implement this test. But it’s simple and easy for those who are programmers Ruby. And now imagine that we have a test designer, who just wrote the script. How to make sure that he could create tests that can be run automatically? That sort of thing Cucumber and deals.
What is it? In fact – it is a text parser, which operates a certain text structures and specific text assigns a block of code in Ruby. This module is available as a separate gem. To install it should run the command line:
1 gem install cucumber
Thus, starting from the definition, we have the plain text test, and raised in compliance with certain blocks of code phrases. That is a separation of description and implementation. In the Cucumber is reflected in the fact that the description of tests stored in a file with the extension *. feature, and the implementation itself is in the file with the extension *. rb. Moreover, the files formed the basis of a specific directory structure. Generally, Cucumber works with the structure formed by the following rules:
Thus, we define the structure, we can create a definition of our test. The catalog features sample.feature create a file and write the definition of a test like this:
1 Feature: Cucumber sample testing
2 Scenario: Sample scenario
3 Given Login into the system
4 When Click on "Search" button
5 Then Search screen is displayed
Here is a sample description of the test in Cucumber. There are marked in bold 5 keywords (not all of the keywords, but the most commonly used):
Now, add the implementation of these steps. In the subdirectory features / step_definitions sample.rb create a file and write it as follows:
01 require ‘test / unit / assertions ‘
02
03
World (Test:: Unit:: Assertions)
04
05 Given "Login into the system" do
06 app.login
07 end
08
09 When "Click on " Search "button" do
10 app.click_button "Search"
11 end
12
13 Then "Search screen is displayed" do
14 assert app.search_screen_displayed? , "No search screen available"
15 end
Everything is ready example. Now start. Cucumber-tests are run from the command line type:
1 cucumber <features_folder>
Navigate to the directory that contains the directory </ b> features </ b> with our definitions of tests and run the command prompt type:
1 cucumber features
Will the execution of the tests and all steps will be made the default output to the console (different types of logging in Cucumber should be considered separately). About how it works. Oh, and add some "flexibility" in our code. As you can see, the call
1 app.click_button "Search"
design accommodates the fact that the right button will be located on a particular text. That is, if we will need to click on, for example, "Select", then it will be realized by calling
1 app.click_button "Select"
If we work with Cucumber, then to provide this flexibility, it is necessary to Given-When-Then the definition can take parameters. And such a possibility. In fact, Ruby-implementation of Given-When-Then do not take a string and regular expression – a pattern in which the text in the feature-file is compared with the corresponding implementation. Accordingly, we can not use a clear agreement between rows, and match the pattern. For example, instead of "Click on " Search "link" can be used / Click on "(.*)" link /.
That we will give. Firstly, the template will use the same template for different variations of the game (when varying only the name of the button). Secondly, Cucumber uses the "back links" that are passed to Given-When-Then implementations of Ruby as parameters. That is, we are considering the implementation can be rewritten as:
01 require ‘test / unit / assertions ‘
02
03
World (Test:: Unit:: Assertions)
04
05 Given "Login into the system" do
06 app.login
07 end
08
09 When / Click on "(.*)" button / do | button |
10 app.click_button button
11 end
12
13 Then "Search screen is displayed" do
14 assert app.search_screen_displayed? , "No search screen available"
15 end
This is only a description of basic features. In fact, this engine is quite extensive and contains a number of "chips" that can afford to create tests, even those who do not have the necessary programming skills. The main thing to ensure the right amount of instruction implemented, then to collect the tests, "brick by brick."