01 What is Gauge
Gauge is a BDD framework for writing and running acceptance tests . It has the following features:
-
Use Markdown’s simple, flexible syntax to describe behavior
-
Supports multiple platforms (Windows, Linux, macOS) and multiple languages (C#, Java, Javascript, Python, Ruby)
-
Support plug-in extension
-
Supports data-driven and external data sources (CSV files)
-
Support VS Code
The use of Markdown syntax to describe behaviors is the most special aspect of Gauge. Next, we will give a detailed explanation, including environment preparation, project initialization, use case writing, data drive, operation, test reports, etc.
02 Environment preparation
1.Install Python
Python installation is relatively simple and will not be described here. The only thing to note is that the python version is required >=2.7
2. Download gauge-1.1.1-windows.x86_64.exe
Download address: https://github.com/getgauge/gauge/releases
The installation is relatively simple, just click Next and finally configure the environment variable for the path where gauge.exe is located. Enter gauge -v in cmder. If the version information is output, it means the installation has been successful.
3. Install the VS Code plug-in
Install gauge plug-in in VS Code
03 Project initialization
In the virtual_workshop directory of drive E, create a gauge_study project directory, switch to this directory, and use the command gauge init python to initialize the project.
The initialization did some directory layering, environment configuration, etc., and gave an example (see example.spec, step_iml.py), which is a project about the statistics of vowels in English words.
The following explains the role of each directory:
-
env: environment configuration directory
-
logs: log directory
-
specs: directory that describes behavior. The spec file stored here is written using MarkDown syntax.
-
step_impl: Implement directory, use python or other languages to perform the behavior described in the spec file
04 Use case writing
1. Write description file
Since it is behavior-driven, there must be a description of the behavior first, and then the implementation of the behavior. Therefore, how to write spec files to describe behaviors and how to implement these behaviors is crucial. Now there is a requirement like this:
Description of Requirement
To test the type and length of a name, the name type is generally a string, and the name length is the sum of each character.
Test name type
The type of name "xxxx" is "string"
Test name length
The length of the name "xxxx" is "4"
In the specs directory, create a name.spec description file. Use MarkDown syntax to implement it as follows:
First explain the rules for writing description files:
In previous test cases, there are concepts of test suites, test sets, test scenarios, and test steps. This concept also applies to Gauge. You can think of the Specs directory as a test suite. Each spec file under it is a test set. Each test set contains one or more test scenarios, and each test scenario contains one or more tests. step. If you understand it this way, many things will become clear at a glance.
Next, we will explain the basic writing method of the description file spec file with examples.
(1) Test set Spec
There can only be one mark for the start of the spec file. Each Spec contains at least one test scenario Scenario. The specific writing method is "# description". Of course, comments can also be added below.
-
This mainly describes the functional modules of the test, such as the name function
# Name
This is a spec file that describe name type and length
(2)Test scenario Scenario
Each Scenario contains at least one test step Step, the specific writing method is "## description".
-
This mainly describes the test scenario, such as testing the type and length of the name. It is a decomposition of the functional modules.
## Test name type
* The type of "Beck" must be "string"
(3)Test step Step
The test step can include the test data "Beck" and the expected result "string", or not. The specific writing method is "* description"
-
Each step is a breakdown of the test scenario
## Test name type
* The type of "Beck" must be "string"
2. Write implementation method
After the description file is prepared, there needs to be implementation of the language, and the relationship between the description file and the implementation method. A brief summary is as follows:
As shown in the figure above, each test method is an implementation of the test step description. You only need to define a method to implement this step. But here comes the question, how should we express the steps with test data and expected results?
-
It's very simple. The positions of all actual parameters can be represented by <variable name>. The steps are only responsible for description. The specific logic of obtaining data, processing data, extracting actual results, and assertions are implemented by the test method. There is a sense of data separation here. Got it
Based on this idea, create a name_impl.py module in the step_impl directory, then introduce the step method from the getgauge.python module, then write the test methods test_name_type and test_name_length, add the @step decorator on the test method, in the decorator The parameters are the content in the description, but they are parameterized using <parameter name> . The parameters in the decorator can be passed to the test method.
05 Data driven
Suppose we want to test multiple names. Obviously, it is unrealistic to write line-by-line step descriptions and define test methods one by one, so we need to use data driver . Gauge supports tables and csv files. Let’s take a look at the table first:
01 form
The table needs to be defined in the description file name.spec. Treat the form as a step, and you need to prepare the corresponding scenarios and steps first
Implement the table batch traversal method test_all_names_by_table in name.spec and add the decorator @step(). The decorator parameter also describes the content in the step "All names that have type and length ", but it also needs to be Add the variable <table> after it. The variable table represents the table object, so the parameter is " All names that have type and length <table> "
So how to traverse each value in the table?
Using table.get_column_values_with_name (column name), you can get an iterable object consisting of each value of the corresponding column, and then use a for loop to traverse it in sequence
02 CSV file
Create a new resources directory under the gauge_study project to store csv files. You can define a names.csv file to store our test data.
Then add a description in the description file name.spec. Just like the table, you need to set up the scenarios and steps. Then you need to add a reference to the csv file address <table:resources/names.csv> in the step description.
Finally, implement the csv data description step in name_impl.py, create a method test_all_names_by_csv_file, add the decorator @step, and the parameter is part of the description " All names that supply by <table> ".
What needs to be noted here is:
Table represents a csv object. The data obtained by traversing the table is the data of each row, such as ["Beck", "string", "4"] in the first row. The elements of this iterable object are decomposed and assigned to name in turn. , type, length, and get every value in the csv file.
06 run
So far, we have written 4 use cases ourselves. Let’s summarize them together:
| Example |
method |
Data storage location |
Remark |
| Test the type of a single name |
test_name_type(name, type) |
Description file name.spec |
|
| Test the length of a single name |
test_name_length(name, type) |
Description file name.spec |
|
| Testing the type and length of multiple names (table) |
test_all_names_by_table(table) |
Description file name.spec |
Use of table.get_column_values_with_name (column name) |
| Test the type and length of multiple names (csv file) |
test_all_names_by_csv_file(table) |
names.csv in the resources directory |
1. Reference to the csv path in the description file 2. Traverse the table to get the data of each row |
How to run these use cases?
-
Gauge provides many methods, including: running all spec files in batches, running specific spec files, and running specific scenarios under specific spec files.
1. Run all spec files
Method: gauge run
或 gauge run specs
Why are there 6 use cases here?
Because it also runs the official samples, there are 2 more items.
2. Run a specific spec file
If you only want to run the 4 use cases under name.spec, you need to add the specified spec file name.
方法：gauge run specs/name.spec
You can see that only 4 use cases were run.
3. Run a specific scenario under a specific spec file
There are 4 scenarios under name.spec, corresponding to 4 use cases. If you only want to run one of the scenarios at this time, such as the scenario of reading table data, how should you write it at this time?
方法：gauge run specs/name.spec:13
What is this 13?
It is actually the line number of the corresponding scene in the name.spec file.
As you can see, only one scenario Test multiple names by table was run.
07 Test report
After running, a reports directory will be automatically generated. Index.html is the final test report, and its relative path is: reports/html-report/index.html
Use the browser to open the report, and I feel that the "appearance" is not bad, and everything has been run successfully here. How about it? Don’t you plan to try such a convenient and fast BDD automated testing framework?
Finally: The complete software testing video tutorial below has been compiled and uploaded. Friends who need it can get it by themselves [guaranteed 100% free]
Software Testing Interview Document
We must study to find a high-paying job. The following interview questions are the latest interview materials from first-tier Internet companies such as Alibaba, Tencent, Byte, etc., and some Byte bosses have given authoritative answers. After finishing this set I believe everyone can find a satisfactory job based on the interview information.
