Models¶
+HttpRunner v3.x uses pydantic to define models of testcase.
diff --git a/dev/models/index.html b/dev/models/index.html new file mode 100644 index 00000000..78761c80 --- /dev/null +++ b/dev/models/index.html @@ -0,0 +1,410 @@ + + + + + +
+ + + + + + + + + + + + + + + +If the SUT (system under test) is ready, the most efficient way is to capture HTTP traffic first and then generate testcases with HAR file. Refer to Record & Generate testcase for more details.
Based on the generated pytest testcase, you can then do some adjustment as needed, thus you need to know the details of testcase format.
-Each testcase is a subclass of HttpRunner, and must have two class attributes: config and teststeps.
base_url, verify, variables, export.One of the most awesome features of HttpRunner v3.x is chain call, with which you do not need to remember any testcase format details and you can get intelligent completion when you write testcases in IDE.


Each testcase should have one config part, in which you can configure testcase level settings.
Specify testcase name. This will be displayed in execution log and test report.
+Specify common schema and host part of the SUT, e.g. https://postman-echo.com. If base_url is specified, url in teststep can only set relative path part. This is especially useful if you want to switch between different SUT environments.
Specify common variables of testcase. Each teststep can reference config variable which is not set in step variables. In other words, step variables have higher priority than config variables.
+Specify whether to verify the server’s TLS certificate. This is especially useful if we want to record HTTP traffic of testcase execution, because SSLError will be occurred if verify is not set or been set to True.
+++SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate in certificate chain (_ssl.c:1076)'))
+
Specify the exported session variables of testcase. Consider each testcase as a black box, config variables is the input part, and config export is the output part. In particular, when a testcase is referenced in another testcase's step, and will be extracted some session variables to be used in subsequent teststeps, then the extracted session variables should be configured in config export part.
Each testcase should have one or multiple ordered test steps (List[Step]), each step is corresponding to a API request or another testcase reference call.

++Notice: The concept of API in HttpRunner v2.x has been deprecated for simplification. You can consider API as a testcase that has only one request step.
+
RunRequest is used in a step to make request to API and do some extraction or validations for response.
The argument name of RunRequest is used to specify teststep name, which will be displayed in execution log and test report.
Specify teststep variables. The variables of each step are independent, thus if you want to share variables in multiple steps, you should define variables in config variables. Besides, the step variables will override the ones that have the same name in config variables.
+Specify HTTP method and the url of SUT. These are corresponding to method and url arguments of requests.request.
If base_url is set in config, url can only set relative path part.
Specify query string for the request url. This is corresponding to the params argument of requests.request.
Specify HTTP headers for the request. This is corresponding to the headers argument of requests.request.
Specify HTTP request cookies. This is corresponding to the cookies argument of requests.request.
Specify HTTP request body. This is corresponding to the data argument of requests.request.
Specify HTTP request body in json. This is corresponding to the json argument of requests.request.
Extract JSON response body with jmespath.
+++with_jmespath(jmes_path: Text, var_name: Text)
+
Besides, variables/extract/validate/hooks mechanisms are supported to create extremely complex test scenarios.