You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the load testing scripts sends requests even if thet return error responses (e.g. sending incorrect credentials returns 401 for subsequent requests).
Checks may be a good option for ensuring successful codes are returned for each request. This could also allow the script to exit early or alert the user if it encounters an error code.
➜ k6 run login.js
# Following errors repeat given bogus password
...
INFO[0009] ~ navigated to the homepage ~ source=console
ERRO[0009] Failed to load resource: the server responded with a status of 401 () browser_source=network line_number=0 source=browser stacktrace="<nil>" url="https://development.aced-idp.org/user/user"
INFO[0009] ~ navigated login page ~ source=console
ERRO[0009] Failed to load resource: the server responded with a status of 404 () browser_source=network line_number=0 source=browser stacktrace="<nil>" url="https://development.aced-idp.org/undefined"
ERRO[0009] Failed to load resource: the server responded with a status of 401 () browser_source=network line_number=0 source=browser stacktrace="<nil>" url="https://development.aced-idp.org/user/user"
INFO[0014] ~ login complete~ source=console
Checks validate boolean conditions in your test. Testers often use checks to validate that the system is responding with the expected content. For example, a check could validate that a POST request has a response.status == 201, or that the body is of a certain size.
Checks are similar to what many testing frameworks call an assert, but failed checks do not cause the test to abort or finish with a failed status. Instead, k6 keeps track of the rate of failed checks as the test continues to run
Each check creates a rate metric. To make a check abort or fail a test, you can combine it with a Threshold.
Check for HTTP response code
Checks are great for codifying assertions relating to HTTP requests and responses. For example, this snippet makes sure the HTTP response code is a 200:
import{check}from'k6';importhttpfrom'k6/http';exportdefaultfunction(){constres=http.get('http://test.k6.io/');check(res,{'is status 200': (r)=>r.status===200,});}
Overview
Currently the load testing scripts sends requests even if thet return error responses (e.g. sending incorrect credentials returns
401
for subsequent requests).Checks may be a good option for ensuring successful codes are returned for each request. This could also allow the script to exit early or alert the user if it encounters an error code.
Example Run with Invalid Credentials
credentials.js
:Running script:
From the k6 docs —
Checks
Checks validate boolean conditions in your test. Testers often use checks to validate that the system is responding with the expected content. For example, a check could validate that a POST request has a
response.status == 201
, or that the body is of a certain size.Checks are similar to what many testing frameworks call an assert, but failed checks do not cause the test to abort or finish with a failed status. Instead, k6 keeps track of the rate of failed checks as the test continues to run
Each check creates a rate metric. To make a check abort or fail a test, you can combine it with a Threshold.
Check for HTTP response code
Checks are great for codifying assertions relating to HTTP requests and responses. For example, this snippet makes sure the HTTP response code is a 200:
Additional Resources:
The text was updated successfully, but these errors were encountered: