Discussion about some features

Ping @netmilk

I think that dredd is a really cool product, and I would like to use it for pretty much every api that I build from now on. However, there is a few things that I don’t know how to best accomplish in dredd at the moment and that is what I would like to open a discussion on.

I have a quick and dirty implementation of what I want in LinusU/mocha-api-blueprint, don’t be fooled by the mocha in the name, that is only a minor part.

I have also created an example of how it is used at LinusU/mocha-api-blueprint-example. This is the beautiful specifications and the strict testing that I want to accomplish.

The first thing that I would like to mention is the response body. I’ve added a feature where I can specify the value as {variableName} and have it accept any value and store it for later. As you can see this makes it possible to test that I can make a POST request and then GET that same resource back.

This also allows me to use assert.deepEqual() for testing the values instead of guessing a JSON-schema for the response. It will make sure that the api actually stores the correct values.

The parameters in the uriTemplates will now fetch the previously stored value if applicable. Please run the tests in mocha-api-blueprint-example to see this in action. The api will return random ids every time but yet it will work beautifully.

That was the most important feature, but I have also integrated very tightly with mocha and I think it would be great if it was very easy to integrate into any existing test frameworks. I think that this would lower the barrier for other people to start using dredd, since it would fit right into their existing setup.

I think that a nice way of doing this is to expose all the transactions that needs to be run to the user, divided by category, and then let the user run them and return the response. This also ties in with the next thing; letting the user send the requests.

Now, I think that this part should be optional; but I think it’s brilliant to let the user run the transaction and return the result, instead of having lots of hooks. It gives the user the most control, and it makes for cleaner code.

We could just have a default handler that does the normal thing.

I realize that this is a lot of very brave changes but what I really want to have is a discussion where we can see how much of this would be feasible to have in dredd, and how much that I should keep outside.

It’s really two issues, the one that allows multiple and stricter tests, and the one that allows tighter integration with existing test frameworks.

Happy coding 🍻

[honzajavorek]

@netmilk @LinusU Feel free to re-open or get to a new issue with more ideas! Closing this now for inactivity.

[honzajavorek]

@netmilk @LinusU Any updates on this?