Enhancing Httprunner Test Cases: Declaration and Reference of Variables
1. Variables
In HttpRunner, there is support for the declaration (variables) and reference (or{var}) mechanism. Variables can be defined using the variables keyword in both config and step, and can be referenced in test steps using or{var}. The difference is:
Variables defined in config are global and can be referenced anywhere in the entire test case (testcase); variables defined in step are limited to the current test step (teststep).
About Variable References:
In most cases, using or{var} is acceptable. However, if there are partial variable references in certain fields, for example, in abc123def where 123 needs to reference a variable, then only the form can be used, that is, {num}def; if using abc, the variable name will be recognized as.Another situation that needs clarification is if the variable itself exists in the test case, then it can be referenced through .
2. Variable Declaration
1. Declaring Global Variables (config variables)
Variables declared under config are global variables for the test case, with a scope that covers the entire test case (.yaml), and can be referenced anywhere in the test case.
config:
name: "Login API"
verify: False
base_url: "https://gitlink.org.cn"
headers:
content-type: "application/json"
variables: # Declare global variables, scope is current .yaml
login: "floraachy"
teststeps:
-
name: Send Login Request
request:
method: POST
url: /api/accounts/login.json
headers:
Content-Type: application/json
body:
autologin: 0
login: ${login} # Here, ${variable_name} is used to reference the config variable login
password: ******
validate: # Assertions
- eq: ["status_code", 200]
- eq: ["body.user_id", 87611]
- eq: ["body.login", $login] # Here, $variable_name is used to reference the config variable login
2. Declaring Local Variables (teststeps variables)
Variables declared under teststep are local variables for the test case, with a scope limited to the current step, and can only be referenced within the current step.
config:
name: "Login API"
verify: False
base_url: "https://gitlink.org.cn"
headers:
content-type: "application/json"
teststeps:
-
name: User 1 Login (Step 1)
variables:
login: floraachy # Variable declared in Step 1 is only effective in the current step
request:
method: POST
url: /api/accounts/login.json
headers:
Content-Type: application/json
body:
autologin: 0
login: ${login}
password: ******
validate:
- eq: ["status_code", 200]
- eq: ["body.login", $login] # Here, login is the variable declared in Step 1, login=floraachy
-
name: User 2 Login (Step 2)
variables:
login: chenyh # Variable declared in Step 2 is only effective in the current step
request:
method: POST
url: /api/accounts/login.json
headers:
Content-Type: application/json
body:
autologin: 0
login: ${login}
password: ******
validate:
- eq: ["status_code", 200]
- eq: ["body.login", $login] # Here, login is the variable declared in Step 2, login=chenyh
If we do not declare the variable login in Step 2 and try to reference the login from Step 1, an error will occur:
3. Variable Priority
In principle, the names of config variables and teststep variables should not be duplicated. When both config and teststep use the same variable, the teststep variable takes precedence over the config variable.
config:
name: "Login API"
verify: False
base_url: "https://gitlink.org.cn"
headers:
content-type: "application/json"
variables:
login: floraachy # login=floraachy defined in config
teststeps:
-
name: User Login
variables:
login: chenyh # login=chenyh defined in teststep
request:
method: POST
url: /api/accounts/login.json
headers:
Content-Type: application/json
body:
autologin: 0
login: ${login} # Here, the actual usage is teststep defined login=chenyh
password: ******
validate:
- eq: ["status_code", 200]
- eq: ["body.login", $login]