Add Assertions in "Run TestCase" steps
Hi
I would like to have assertions in "Run TestCase" steps, just like in "normal" HTTP-, SOAP-, REST request steps.
Now I have to do the assertions with a separate script-step. This represents some drawbacks:
1. When copying a "Request" ("Run TestCase") step, you also have to remember to copy the assertion, otherwise the test step will pass automatically.
2. If you make a lot of requests using "Run TestCase", you will need a lot of extra "script" steps, who need distinctive names. Confusing and difficult to overview with all "extra" steps.
If there is difficulty in implementing it because of not knowing what will be performed in the target testcase (the one being run), at least a "script" assertion would be great.
E.g.
We use "common" testcases that are called many times from different test cases. Some things can be asserted in those "common" test cases, but some assertions are very specific and needs to be verified in the "calling" test case. Having them included in the calling test step would make it much "cleaner" instead of having to make a separate "scrips" step to perform the assertions.
Best regards,
Tommy
I would like to have assertions in "Run TestCase" steps, just like in "normal" HTTP-, SOAP-, REST request steps.
Now I have to do the assertions with a separate script-step. This represents some drawbacks:
1. When copying a "Request" ("Run TestCase") step, you also have to remember to copy the assertion, otherwise the test step will pass automatically.
2. If you make a lot of requests using "Run TestCase", you will need a lot of extra "script" steps, who need distinctive names. Confusing and difficult to overview with all "extra" steps.
If there is difficulty in implementing it because of not knowing what will be performed in the target testcase (the one being run), at least a "script" assertion would be great.
E.g.
We use "common" testcases that are called many times from different test cases. Some things can be asserted in those "common" test cases, but some assertions are very specific and needs to be verified in the "calling" test case. Having them included in the calling test step would make it much "cleaner" instead of having to make a separate "scrips" step to perform the assertions.
Best regards,
Tommy
