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
Beth Skurrie edited this page Nov 28, 2016
·
7 revisions
Because I'm short on time right now, I'm going to copy-paste this conversation from gitter which I think explains it well.
Pierre Vincent @PierreVincent 05:09
This is pretty subtle, but I find when testing for error scenarios like these (which are pretty much “validation failed” scenarios), the scenario should not specify the why of the validation failure, but more than for some reason validation failed.
What the contract is there to validate is how the server responds when rejecting a request, but not why it rejects the request.
So rather than naming your scenario using validation rules of the provider (which is provider business logic), just name your scenario about a failure case.
Ex:
"description": "a request to allocate stock to a product",
"provider_state": "the product can be allocated",
expected status: 200 OK
"description": "a request to allocate stock to a product",
"provider_state": "the product cannot be allocated",
expected status: 400 BAD REQUEST
This is much nicer to allow flexibility to the provider to manage its own validation rules.