-
Notifications
You must be signed in to change notification settings - Fork 281
Multiple Responses aren't supported #25
Comments
This is definitely a limitation we'd like to overcome. |
Hi @rjocoleman, |
@netmilk You can define multiple responses in the blueprint, but Dredd isn't aware of them yet (it doesn't know how to pair example requests with example responses). At the moment it ignores additional requests/response per endpoint. I'm not sure what the AST looks like now, but it may have enough information to properly pair a requests and responses? I tried to implement this a while back but found that I didn't have enough information to do so. |
@ecordell Multiple request and response pairs are part of the AST in the new Protagonist 0.10.0. I already have upgrade of Protagonist in Dredd in my TODO queue. |
After update to the latest protagonist AST, there is possible to specify multiple request and response pairs. Multiple responses or requests are still omitted. So if you want to test multiple different responses for a single URI endpoint you have to specify request for each single response. Unfortunately there is no way how to specify different query (URI) parameter for each request and invoke particular response, yet.
|
Any plans for this? |
Please refer to this comment. I will create some example on this, definitely soon. |
Is there anyway to use a before hook multiple times on the same name/api call? I have an API that has several different responses, depending on the request, and I'm trying to get dredd to test each response possibility. I can modify my request using a before hook, but multiple before hooks on the same hook are modify the single request. |
@GregorioDiStefano If you have given multiple request and responses under one action, It should compile to multiple examples and you should be able to address them in hooks. See output of Would you mind sharing some snippet of your API Blueprint with me? |
The discussion about how to address multiple request and responses in the future is being discussed here: #227 (comment) |
This is what I'm working with: ### Devices in deplyment [GET /api/0.0.1/deployments/{deployment_id}/devices]
Device statuses for the deployment.
+ Parameters
+ deployment_id: `f81d4fae-7dec-11d0-a765-00a0c91e6bf6` (string,required) - Deployment identifier
+ Response 200 (application/json)
+ Attributes (array)
+ attribute (DeploymentStatic)
+ id: `00a0c91e6-7dec-11d0-a765-f81d4faebf6` (string) - Device identifier
+ status: `pending` (enum[string]) - Deployment status
+ Members
+ `pending` - Pending to start
+ `inprogress` - In progress
+ `success` - Finished with success
+ `failure` - Finished with failure
+ `noimage` - Do not have apropriate image for the device model.§
+ finished: `2009-11-10 24:00:00 +0000 UTC` (string, optional) - Deployment finish time
+ Response 404 (application/json)
+ Attributes (Error)
+ Response 500 (application/json)
+ Attributes (Error)
```
I'm interested in testing the 404 and 500 errors as well, is the only way to split this in to separate request and responses? |
Sill not getting anywhere, I've tried with the following: ### Deployment status [GET]
Check status for specified deployment
+ Parameters
+ id: `f81d4fae-7dec-11d0-a765-00a0c91e6bf6` (string,required) - Deployment identifier
+ Response 200 (application/json)
+ Attributes (DeploymentStatic)
+ id: `f81d4fae-7dec-11d0-a765-00a0c91e6bf6` (string)
+ finished: `2009-11-10 24:00:00 +0000 UTC` (string, optional) - Deployment finish time
+ status: `pending` (enum[string]) - Current deployment state
+ Members
+ `pending` - Pending to start
+ `inprogress` - In progress
+ `success` - Finished with success
+ `failure` - Failed
+ Request
+ id: `f81d4fae-7dec-11d0-a765-00000000000` (string,required) - Deployment identifier
+ Response 404 (application/json)
+ Attributes (Error) but my original parameter f81d4fae-7dec-11d0-a765-00a0c91e6bf6 is being overwritten with the re-declared value f81d4fae-7dec-11d0-a765-00000000000. |
This feature would help clean up our docs. We currently have to have empty
This results in the warning: This is only an issue for GET requests with different responses. Still, it would be less clumsy if Dredd could just check how many responses there are instead of insisting requests and responses be paired. tl;dr +1 |
This change tests and fixes a problem introduced with migration to API Elements in order to support Swagger in Dredd. Original implementation always selected the first request-response pair from each transaction example. This wasn't re-implemented correctly on top of API Elements. Instead, all specified responses are appearing, which breaks Dredd's behavior in many ways. Respective test was ported, but unfortunately with the same mistake. This commit fixes the situation. Some early adopters discovered the issue and considered it to be a new feature, but it really breaks how Dredd should work at the moment and needs to be removed. It leads to duplicate transaction names and other undefined behavior. In order to implement #25 and #78, which many believed happened when they discovered the bug, much more work needs to be done. Namely designing and adopting a new way of addressing transactions in Dredd #227. Closes #615 BREAKING CHANGE
This change fixes a problem introduced with migration to API Elements in order to support Swagger in Dredd. Original implementation always selected the first request-response pair from each transaction example. This wasn't re-implemented correctly on top of API Elements. Instead, all specified responses are appearing, which breaks Dredd's behavior in many ways. Respective test was ported, but unfortunately with the same mistake. Some early adopters discovered the issue and considered it to be a new feature, but it really breaks how Dredd should work at the moment and needs to be removed. It leads to duplicate transaction names and other undefined behavior. In order to implement apiaryio/dredd#25 and apiaryio/dredd#78, which many believed happened when they discovered the bug, much more work needs to be done. Namely designing and adopting a new way of addressing transactions in Dredd apiaryio/dredd#227. BREAKING CHANGE
This change tests and fixes a problem introduced with migration to API Elements in order to support Swagger in Dredd. Original implementation always selected the first request-response pair from each transaction example. This wasn't re-implemented correctly on top of API Elements. Instead, all specified responses are appearing, which breaks Dredd's behavior in many ways. Respective test was ported, but unfortunately with the same mistake. This commit fixes the situation. Some early adopters discovered the issue and considered it to be a new feature, but it really breaks how Dredd should work at the moment and needs to be removed. It leads to duplicate transaction names and other undefined behavior. In order to implement #25 and #78, which many believed happened when they discovered the bug, much more work needs to be done. Namely designing and adopting a new way of addressing transactions in Dredd #227. Closes #615 BREAKING CHANGE
BREAKING CHANGE: This change tests and fixes a problem introduced with migration to API Elements in order to support Swagger in Dredd. Original implementation always selected the first request-response pair from each transaction example. This wasn't re-implemented correctly on top of API Elements. Instead, all specified responses are appearing, which breaks Dredd's behavior in many ways. Respective test was ported, but unfortunately with the same mistake. This commit fixes the situation. Some early adopters discovered the issue and considered it to be a new feature, but it really breaks how Dredd should work at the moment and needs to be removed. It leads to duplicate transaction names and other undefined behavior. In order to implement #25 and #78, which many believed happened when they discovered the bug, much more work needs to be done. Namely designing and adopting a new way of addressing transactions in Dredd #227. Closes #615
+1 |
It appears that multiple responses aren't supported. This limits the usefulness of
dredd
when using something likegrunt
orguard
.My use case is creating a subscriber, when a subscriber is created successfully 200. When it's a duplicate it's a 422. First test will create the subscriber and all subsequent tests will fail
The text was updated successfully, but these errors were encountered: