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
-[Write and run your first test suite](#write-and-run-your-first-test-suite)
44
45
-[Export tests report](#export-tests-report)
@@ -695,6 +696,45 @@ Example:
695
696
# Remaining steps in this context will not be executed
696
697
```
697
698
699
+
#### Custom assertions
700
+
701
+
It is possible to use the [user defined executors syntax](#user-defined-executors) and prefixing your executor name with `Should` to create a new custom assertion keyword.
702
+
703
+
Example:
704
+
```yml
705
+
# lib/ShouldBeHttp2XX.yml
706
+
executor: ShouldBeHttp2XX
707
+
steps:
708
+
- assertions:
709
+
- a ShouldBeGreaterThanOrEqualTo 200
710
+
- a ShouldBeLessThan 300
711
+
```
712
+
713
+
You may also include additional steps like a regular user defined executor.
714
+
715
+
Custom assertions are executed in an entirely clean context, containing only the following variables:
716
+
- `a`: the left operand
717
+
- `b`: the (first) right operand
718
+
- `argv`: the rights operands
719
+
720
+
If you need to be compatible with the `input` syntax of user defined executors, you could use the `argv` as the default value and access these through the regular `input.*` syntax.
721
+
```yaml
722
+
input:
723
+
test: "{{.argv.argv1}}"
724
+
```
725
+
726
+
To call a registered custom assertions, just use its registered name in the `assertions` array, like any built-in assertion keyword.
727
+
728
+
```yml
729
+
# test.yml
730
+
testcases:
731
+
- steps:
732
+
- type: http
733
+
url: https://example.com
734
+
assertions:
735
+
- result.statuscode ShouldBeHttp2XX
736
+
```
737
+
698
738
### Using logical operators
699
739
700
740
While assertions use `and` operator implicitly, it is possible to use other logical operators to perform complex assertions.
0 commit comments