2

I have a question about Rails Integration Tests. I have this app that talks to this other internal app.

The app makes a request to internal_app, and one of the params for that request involves the session_id, stored in the session cookie. For a variety of reasons, requests to external services are stubbed out using webmock and vcr gems. This records the request/response to a fixture file, so that the next time the request is run, it hits the fixture file instead of the real service.

My issue, is that the session_id changes each time the test is run. This means that, according to webmock, the request made does not match the request stubbed, which leads to a failed test. In controller tests, I can access the session directly, and change/stub whatever I want in there as desired. With integration tests, I cannot access the session directly, and so I am stuck using whatever session_id Rails generates for the test. Does anyone know of a good way to modify/stub the session_id for integration tests, to something expected? There are some less preferred ways I am considering (involving ditching the vcr gem for those integration tests for example), but I would prefer to find a way to have session_id be some expected value instead.

Tests are made with Capybara/Poltergeist/phantomjs, on a Rails 5.1 application.

mc92
  • 475
  • 5
  • 10

1 Answers1

1

You really shouldn't be stubbing internals of your app during integration tests since it really defeats the point of integration tests. You can however configure VCR to ignore the session_id using the :match_requests_on option - https://relishapp.com/vcr/vcr/docs/request-matching - when matching the request and then use dynamic cassettes - https://relishapp.com/vcr/vcr/v/3-0-3/docs/cassettes/dynamic-erb-cassettes - to insert the correct session_id into the response if necessary

Thomas Walpole
  • 48,548
  • 5
  • 64
  • 78
  • Thanks for that. I'll try it out. I'm curious, how would you approach the stubbing/not stubbing issue? The integration test still hits the controller, and the controller still executes the code that tries to make the request to an external service. In this case, I would think that external service request should still be stubbed? – mc92 Jun 29 '18 at 21:03