-
Notifications
You must be signed in to change notification settings - Fork 4
Description
π«΄ Proposal
I don't have clear solution for my vision yet but the goal is to have possibility to somehow mark requests, which are critical - if they fail, the other following requests don't make any sense to be executed (because they would 100% fail as well). This can optimize testing runs and omit execution of irrational requests.
It can look like this:
### GET Created product
## CRITICAL-REQUEST
GET {{URL}}
The problem is how to determine on which level it is critical - it can influence only test cases within current folder, or it can go beyond. This needs to be wisely designed, so the user experience is met with ease of implementation.
β¨ Motivation
Sometimes, when some request fails, it triggers domino effect of failing requests/tests. Execution of the requests/tests that will fail for sure is completely unnecessary and should be omitted at all.
π Alternatives
It is not always only one request which is critical, but whole test case can be indicator of future failures. Therefore, maybe similar approach can be applied on test case level.
π‘ Possible implementation
If it would be solved by directive, there has to be added a new ILineParser, which will be registered in the list of available line parsers within DirectivesLineParser.
After failure of critical request, the next test which should be executed has to be scheduled in ApplicationContext. This way, test cases will be able to appropriately determine, whether they should be executed or no - method ShouldExecute will be modified (this is already suggested in #62)
β Additional context
This issue is derived from #2, which already propose this functionality.