Skip to content
This repository was archived by the owner on Nov 8, 2024. It is now read-only.

Multiple Responses aren't supported #25

Open
rjocoleman opened this issue Nov 20, 2013 · 14 comments
Open

Multiple Responses aren't supported #25

rjocoleman opened this issue Nov 20, 2013 · 14 comments

Comments

@rjocoleman
Copy link

It appears that multiple responses aren't supported. This limits the usefulness of dredd when using something like grunt or guard.

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

$ dredd apiary.apibp http://localhost:3000/
INFO: Runtime compilation warning: Multiple responses, using first.
 on  > Subscribers > Creating a Subscriber
@Almad
Copy link

Almad commented Nov 26, 2013

This is definitely a limitation we'd like to overcome.

@netmilk
Copy link
Contributor

netmilk commented Mar 12, 2014

Hi @rjocoleman,
multiple responses are now supported in the latest release of API Blueprint. Is this what are you looking for?
A

@ecordell
Copy link
Contributor

ecordell commented Apr 1, 2014

@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.

@netmilk
Copy link
Contributor

netmilk commented Apr 2, 2014

@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.

@netmilk
Copy link
Contributor

netmilk commented Jul 1, 2014

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.

# Resource [/]
## Do Someting [POST]

+ request A

        A

+ response 200

        200

+ request B

        B

+ response 200

        400

@arvenil
Copy link

arvenil commented Jan 2, 2015

Any plans for this?

@netmilk
Copy link
Contributor

netmilk commented Jan 15, 2015

Please refer to this comment. I will create some example on this, definitely soon.

@GregorioDiStefano
Copy link

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.

@netmilk
Copy link
Contributor

netmilk commented Feb 29, 2016

@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 --names

Would you mind sharing some snippet of your API Blueprint with me?

@netmilk
Copy link
Contributor

netmilk commented Feb 29, 2016

The discussion about how to address multiple request and responses in the future is being discussed here: #227 (comment)

@GregorioDiStefano
Copy link

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?

@GregorioDiStefano
Copy link

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.

@netmilk netmilk mentioned this issue Mar 1, 2016
12 tasks
@hueter
Copy link

hueter commented Jun 22, 2016

This feature would help clean up our docs.

We currently have to have empty Request headers to enable separate Dredd hooks for different responses like so:

+ Request Bad 
+ Response 400
+ Request Not Found
+ Response 404

This results in the warning: warn: Parser warning in file 'apiary.apib': (6) empty request message-body on line 689

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

honzajavorek added a commit that referenced this issue Aug 24, 2016
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
honzajavorek added a commit to apiaryio/dredd-transactions that referenced this issue Aug 24, 2016
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
honzajavorek added a commit that referenced this issue Aug 24, 2016
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
honzajavorek added a commit that referenced this issue Aug 24, 2016
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
@austinmcorso
Copy link

+1

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants