GithubBackup/httprunner
1
0
Fork 0
mirror of https://github.com/httprunner/httprunner.git synced 2026-05-15 04:19:28 +08:00
Code Issues Packages Projects Releases Wiki Activity

validate: set expect as alias for expected

Browse Source
This commit is contained in:
debugtalk
2017-11-13 20:56:46 +08:00
parent 40651e5164
commit 3af67a31cc
16 changed files with 117 additions and 114 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
docs/quickstart.md
View File

@@ -66,8 +66,8 @@ Open your favorite text editor and you can write test cases like this.
name: "user1"
password: "123456"
validate:
- {"check": "status_code", "comparator": "eq", "expected": 201}
- {"check": "content.success", "comparator": "eq", "expected": true}
- {"check": "status_code", "comparator": "eq", "expect": 201}
- {"check": "content.success", "comparator": "eq", "expect": true}
```
As you see, each API request is described in a `test` block. And in the `request` field, it describes the detail of HTTP request, includes url, method, headers and data, which are in line with the captured traffic.
@@ -123,8 +123,8 @@ To fix this problem, we should correlate `token` field in the second API test ca
extract:
- token: content.token
validate:
- {"check": "status_code", "comparator": "eq", "expected": 200}
- {"check": "content.token", "comparator": "len_eq", "expected": 16}
- {"check": "status_code", "comparator": "eq", "expect": 200}
- {"check": "content.token", "comparator": "len_eq", "expect": 16}
- test:
name: create user which does not exist
@@ -138,8 +138,8 @@ To fix this problem, we should correlate `token` field in the second API test ca
name: "user1"
password: "123456"
validate:
- {"check": "status_code", "comparator": "eq", "expected": 201}
- {"check": "content.success", "comparator": "eq", "expected": true}
- {"check": "status_code", "comparator": "eq", "expect": 201}
- {"check": "content.success", "comparator": "eq", "expect": true}
```
As you see, the `token` field is no longer hardcoded, instead it is extracted from the first API request with `extract` mechanism. In the meanwhile, it is assigned to `token` variable, which can be referenced by the subsequent API requests.
@@ -205,8 +205,8 @@ And then, we can revise our demo test case and reference the functions. Suppose
extract:
- token: content.token
validate:
- {"check": "status_code", "comparator": "eq", "expected": 200}
- {"check": "content.token", "comparator": "len_eq", "expected": 16}
- {"check": "status_code", "comparator": "eq", "expect": 200}
- {"check": "content.token", "comparator": "len_eq", "expect": 16}
- test:
name: create user which does not exist
@@ -220,8 +220,8 @@ And then, we can revise our demo test case and reference the functions. Suppose
name: "user1"
password: "123456"
validate:
- {"check": "status_code", "comparator": "eq", "expected": 201}
- {"check": "content.success", "comparator": "eq", "expected": true}
- {"check": "status_code", "comparator": "eq", "expect": 201}
- {"check": "content.success", "comparator": "eq", "expect": true}
```
In this revised test case, `variable reference` and `function invoke` mechanisms are both used.
@@ -269,8 +269,8 @@ To handle this case, overall `config` block is supported in `HttpRunner`. If we
extract:
- token: content.token
validate:
- {"check": "status_code", "comparator": "eq", "expected": 200}
- {"check": "content.token", "comparator": "len_eq", "expected": 16}
- {"check": "status_code", "comparator": "eq", "expect": 200}
- {"check": "content.token", "comparator": "len_eq", "expect": 16}
- test:
name: create user which does not exist
@@ -283,8 +283,8 @@ To handle this case, overall `config` block is supported in `HttpRunner`. If we
name: "user1"
password: "123456"
validate:
- {"check": "status_code", "comparator": "eq", "expected": 201}
- {"check": "content.success", "comparator": "eq", "expected": true}
- {"check": "status_code", "comparator": "eq", "expect": 201}
- {"check": "content.success", "comparator": "eq", "expect": true}
```
As you see, we define variables in `config` block. Also, we can set `base_url` in `config` block, thereby we can specify relative path in each API request url. Besides, we can also set common fields in `config` `request`, such as `device_sn` in headers.

20
docs/write-testcases.rst
View File

@@ -40,8 +40,8 @@ And here is testset example of typical scenario: get `token` at the beginning, a
extract:
- token: content.token
validate:
- {"check": "status_code", "comparator": "eq", "expected": 200}
- {"check": "content.token", "comparator": "len_eq", "expected": 16}
- {"check": "status_code", "comparator": "eq", "expect": 200}
- {"check": "content.token", "comparator": "len_eq", "expect": 16}
- test:
name: create user which does not exist
@@ -54,8 +54,8 @@ And here is testset example of typical scenario: get `token` at the beginning, a
name: "user1"
password: "123456"
validate:
- {"check": "status_code", "comparator": "eq", "expected": 201}
- {"check": "content.success", "comparator": "eq", "expected": true}
- {"check": "status_code", "comparator": "eq", "expect": 201}
- {"check": "content.success", "comparator": "eq", "expect": true}
Function invoke is supported in `YAML/JSON` format testcases, such as `gen_random_string` and `get_sign` above. This mechanism relies on the `debugtak.py` hot plugin, with which we can define functions in `debugtak.py` file, and then functions can be auto discovered and invoked in runtime.
@@ -68,7 +68,7 @@ Comparator
``HttpRunner`` currently supports the following comparators.
+---------------------------+---------------------------+-------------------------+--------------------------+
| comparator | Description | A(check), B(expected) | examples |
| comparator | Description | A(check), B(expect) | examples |
+===========================+===========================+=========================+==========================+
| ``eq``, ``==`` | value is equal | A == B | 9 eq 9 |
+---------------------------+---------------------------+-------------------------+--------------------------+
@@ -171,11 +171,11 @@ There might be slight difference on list, cos we can use index to locate list it
- content_type: headers.content-type
- first_name: content.person.name.first_name
validate:
- {"check": "status_code", "comparator": "eq", "expected": 200}
- {"check": "headers.content-type", "expected": "application/json"}
- {"check": "headers.content-length", "comparator": "gt", "expected": 40}
- {"check": "content.success", "comparator": "eq", "expected": True}
- {"check": "content.token", "comparator": "len_eq", "expected": 16}
- {"check": "status_code", "comparator": "eq", "expect": 200}
- {"check": "headers.content-type", "expect": "application/json"}
- {"check": "headers.content-length", "comparator": "gt", "expect": 40}
- {"check": "content.success", "comparator": "eq", "expect": True}
- {"check": "content.token", "comparator": "len_eq", "expect": 16}