Support swagger files

[bethesque]

Support swagger files

[gonzalo-bulnes]

Hi @bethesque,

It don't see any reason why it could not, but I'm not familiar with the Swagger-side of Dredd. What do you think would be required for Dredd::Rack to expose that feature properly?

[bethesque]

The only difference in running dredd seems to be the argument passed through to the underlying dredd process. See https://dredd.readthedocs.io/en/latest/quickstart.html#test-your-api

$ dredd api-description.apib http://127.0.0.1:3000  # API Blueprint
$ dredd api-description.yml http://127.0.0.1:3000  # Swagger

Potentially, it just requires a few changes to method names including blueprint and some different file extension filters. eg. The README says "However, it relies on the following convention: API blueprints must be stored in the doc directory with either the .apib or the .apib.md extension".

Perhaps I can configure it manually to pick up the yaml file?

[gonzalo-bulnes]

That makes perfect sense. The path_to_blueprints is currently hardcoding the doc/*.apib doc/*apib.md convention in the Dredd::Rack::Runner, so it is not configurable.

That being said, I see no reason why not to make it a configuration option. I just don't use to add any options until someone actually needs them : )

Making that parameter a configuration option should be very similar to what adding the dredd_command option (#29) has been some time ago. (Plus updating the section that you mentioned from the README.)

The usage would then look something like:

# config/initializers/dredd-rack.rb or app.rb or Rakefile

require 'dredd/rack'

Dredd::Rack.configure do |config|
  # Allow the automatic setup of a local application server when necessary
  #
  # Find the name of your application in its `config.ru` file.
  config.app = Example::Application # or Rails.application, Sinatra::Application...

  # Use Swagger files:
  config.path_to_blueprints = 'doc/*.yml other/path/*.yaml'
end

What do you think @bethesque? Do you want give it a go and open a PR? I can do it too, but contributions make my day! ; ) (no pressure, however)

[gonzalo-bulnes]

Indeed path_to_blueprints could be either renamed to something that would cover both API blueprints and Swagger files, or maybe aliased (I'm not sure if aliasing could be source of confusion, it might not be a good idea?). Any thoughts?

[bethesque]

I'd be inclined to rename the method to a generic term, but alias it with a deprecation warning for backwards compatibility.

I have to admit now, we've gone with a "manual" solution for running our dredd tests because it's easier to reuse the existing application start and stop tasks that keep it inline with our integration tests. I'm going to close this issue because, as you rightly point out, there's no point doing work unless somebody wants it! Thank you for being open to the suggestion.

I'll come back to this for our next swagger/dredd API ;)

[gonzalo-bulnes]

Hi @bethesque,

It turns out that having used Dredd in a Go project for a while, my team and I also moved to a handcrafted solution to replace it not that far ago. Integration testing is not a simple work flow and I'm getting to think that finding something that fits really well can be worth maintaining some custom logic.

Thanks for the feedback! I'll be happy to re-open this when it makes sense : )