zipmark / rspec_api_documentation

Automatically generate API documentation from RSpec
MIT License
1.45k stars 363 forks source link

Get `NoMethodError` when there is an example that expect an api to raise 500 error #473

Open khiav223577 opened 4 years ago

khiav223577 commented 4 years ago

The example that will cause the problem:

it do
  expect{ subject }.to raise_error(RuntimeError, 'Invalid Buffer')
end

Backtraces

         9: from /home/khiav/.rvm/gems/ruby-2.5.5/gems/mustache-1.1.1/lib/mustache/context.rb:112:in `each'
         8: from /home/khiav/.rvm/gems/ruby-2.5.5/gems/mustache-1.1.1/lib/mustache/context.rb:116:in `block in fetch'
         7: from /home/khiav/.rvm/gems/ruby-2.5.5/gems/mustache-1.1.1/lib/mustache/context.rb:148:in `find'
         6: from /home/khiav/.rvm/gems/ruby-2.5.5/gems/mustache-1.1.1/lib/mustache/context.rb:148:in `call'
         5: from /home/khiav/.rvm/gems/ruby-2.5.5/gems/rspec_api_documentation-6.1.0/lib/rspec_api_documentation/views/api_blueprint_example.
rb:22:in `requests'
         4: from /home/khiav/.rvm/gems/ruby-2.5.5/gems/rspec_api_documentation-6.1.0/lib/rspec_api_documentation/views/markup_example.rb:50:i
n `requests'
         3: from /home/khiav/.rvm/gems/ruby-2.5.5/gems/rspec_api_documentation-6.1.0/lib/rspec_api_documentation/views/markup_example.rb:16:i
n `method_missing'
         2: from /home/khiav/.rvm/gems/ruby-2.5.5/gems/rspec_api_documentation-6.1.0/lib/rspec_api_documentation/example.rb:58:in `requests'
         1: from /home/khiav/.rvm/gems/ruby-2.5.5/gems/rspec_api_documentation-6.1.0/lib/rspec_api_documentation/example.rb:65:in `filter_hea
ders'
/home/khiav/.rvm/gems/ruby-2.5.5/gems/rspec_api_documentation-6.1.0/lib/rspec_api_documentation/example.rb:71:in `remap_headers': undefined m
ethod `each' for nil:NilClass (NoMethodError)
RaviAsnani commented 4 years ago

+1

bf4 commented 3 years ago

seems like we just need buy-in to write a PR to fix it (and how it should fix it)

jakehow commented 3 years ago

@bf4 In general I'm of the opinion that your API endpoints shouldn't knowingly raise, and you should have a catch all for situations you didn't predict, but maybe there's a reason to do this?

bf4 commented 3 years ago

In our case I had an acceptance test that asserted the action wasn't routed

    example "PATCH update" do
      expect {
        do_request
      }.to raise_error(ActionController::RoutingError, /No route matches/)
    end

which I think is reasonable, though I should probably just tag it as document: false in that case, I suppose. Maybe that's the fix? rescue the error and asked if you mean to mark document: false?

jakehow commented 3 years ago

@bf4 does your app not rescue this error and provide a response to the client?