Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Revamp the Rails integration's tests
* Remove extraneous spans that were being generated due to the ActiveSupport::Notifications subscriptions. There's no need to actually configure these from the tests, since we already have the active_support_spec.rb, and it's not like the config in the rails_spec.rb even matched the one from the Rails generator or anything. These just get in the way of testing the Rails integration, since the custom fields we'd want to make assertions about only wind up on the root span anyway. * Factor out assertions into a set of shared examples, and actually start making assertions about the `request.{action,controller,route}` fields that the integration adds (which weren't even being tested for previously 😱). * Rework the "bad request" tests that reproduce honeycombio#49. These tests will now break against the old implementation, since they assert that routing information is still present (whereas honeycombio#50 wipes the fields out with error messages). There are ways to get the routing information without ever trying to parse the GET/POST parameters, so we can still save this use case. Furthermore, the only Rails 5+ specific changes are to whether or not Rails responds with an HTTP 400, so we needn't wipe out the entire `describe` block for Rails < 5. * Add tests to reproduce the issue described in honeycombio#62, where unrecognized routes may cause the old implementation to erroneously fall back to the GET/POST parameters for routing information. * Add tests that reproduce honeycombio#31. The bug is actually in the twirp gem, whose middleware fails to rewind the `rack.input` after reading it. I've verified these regression tests against the old version of the Rails integration that didn't check `if request.raw_post`, and they fail appropriately. I wanted to have this test in here to have confidence in changing the implementation of the Rails integration. The `raw_post` workaround of honeycombio#39 is unnecessary if we actually never look at the GET/POST parameters in the first place (no parsing, no problem).
- Loading branch information