-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Way to relax isBodyEqual
comparison?
#46
Comments
@lettertwo this is something @marcelogo and I have discussed a lot during the course of Drakov's evolution, as well as with others who have used it. Perhaps we need to look at properly documenting the goals of Drakov as a tool and where it fits in terms of testing and how to best use it - one of these goals being to maintain it's stateless nature. In the context of reading and using the Blueprint API specs, we want to 100% respect those as well. In terms of providing proper API test coverage, you should use a tool such as Dredd to exercise the Blueprint API contract against the real API. Dredd as an API tool provides other means to assert the response via JSON schemas, as well the better known static example response bodies. Getting back to the usage of Drakov, our intention is that tests using Drakov as a backend should not test state, but simply behaviours in the interface. We have had ideas and discussions with people who use Drakov about adding some sort of a "state" machine in a middleware that can isolate state to a specific test, but we haven't had the time yet to explore this. We are always happy to hear the thoughts of Drakov's users, so feel free to give any feedback. I may even think about in the near future starting another project for a middleware module that can be implemented as a state machine of some sort. Until we have better documentation @lettertwo I'll keep this as an open issue so this discussion can continue with anyone who has thoughts about this. 👍 |
@yakovkhalinsky thanks for the quick, thoughtful response. I think I was a little unclear about my use case, so let me try to clarify. I don't want drakov to know about any state. I have an API consumer that makes POST requests. Currently, drakov rejects those requests unless the payload exactly matches what's in the API doc. This makes it impossible to use drakov when testing user-entered data. So for example, if the user enters a different name in a form than what is in the API spec, the request will fail. I'd like this validation to be relaxed. |
OK, perhaps we could look at implementing JSON schema as a way of matching the request body. Response body will still be the same though, would that still work in your usecase @lettertwo ? |
Just an update. I've had a brief discussion with @marcelogo and we'll see if we can work this into next week's release. |
@yakovkhalinsky @marcelogo 👍 yeah, that sounds good to me–I want to be able to test that the request is formed correctly, so the only thing that matters from the response is that it succeeds or fails. |
We released feature to use JSON Schema to match the request body against the specification. It should relax the comparison given that you won't need a body example on the request to ensure the equality. |
@lettertwo |
Currently, when making a POST request to drakov, the (json or form-encoded) request body must exactly match the example request body in the spec. This prevents basic testing of application request logic against the mock, because your app won't always be sending the same body content. Should the checking be relaxed (i.e. just checking to see if keys are present), or even removed completely?
I'm happy to submit a PR if either of these (or something else I haven't thought of here) sounds good.
The text was updated successfully, but these errors were encountered: