Adds reset_session_after_each config option #419

Closed
wants to merge 2 commits into
from

Projects

None yet

8 participants

@kberridge

Closes issue #418.

Allows user to set Capybara.reset_session_after_each = false.
This will prevent the session from being cleared after each rspec test.

Collaborator
joliss commented Jul 25, 2011

From #418:

But there are times when I would prefer that management of the session state was left up to me (ex: to avoid the need to login before every test).

Aren't tests supposed to be independent? That is, aren't you introducing subtle dependencies on the execution order of your tests if you rely on your session persisting?

Yes! But I'm controlling the scope of those side effects using a wipe => :true selector on my describe blocks. I have a config.after(:all, :wipe => :true) hook that clears the database and wipes the session.

This allows me to not have to login (for example) before every single test.

It certainly gives me the power to shoot myself in the foot if I'm not careful, so I can understanding leaving capybara's default reset_session_after_each to true. But it also gives me the power to control exactly when state gets wiped, which is useful for improving test run times, and for writing nested describes.

I would like to use areset_session_after_each config option as well for the same reasons @kberridge mentioned.

Collaborator
joliss commented Jul 29, 2011

I like the use case -- speeding up tests is always good -- but I wonder if it's not something that belongs into RSpec.

After all, there may be other gems (like DatabaseCleaner) registering before/after hooks that you'd also have to stop from running. Plus perhaps even your own context-specific setup and teardown code. I think this could reasonably be handled in a central place by RSpec.

I also wonder if there isn't a better alternative to the :wipe => true syntax, by the way. For example, you could write it this way:

describe do
  before :each
  it 'T1'
  it 'T2', :readonly => true
  it 'T3'
  after :each
end

Where :readonly indicates that a test doesn't modify its environment. This way the default behavior is still "safe", and you can't accidentally forget to set :wipe. So if B stands for all before hooks (both context-specific and anything registered by libraries like Capybara), and A for after hooks, then this might example be run as:

 B T1 A B T2 T3 A

thereby saving one A B (teardown and setup) cycle.

Hm. Just brainstorming.

The way we've been writing our rspec acceptance tests, all the it blocks are "readonly" and the describe blocks are what are what modify state. So that's why we put the :wipe => true on the describe block.

This allows you to nest describes and have the outer one do the wipe while the inner ones modify different state.

Collaborator

I'm not 100% convinced of this. It's a pretty uncommon usecase, and in case you really need it, you can hook Capybara into RSpec yourself, it's not a lot of code, and you can get full control over everything.

For the record, I solved the same problem by using token authentication, as opposed to username/password. On the first request, you just send the token and boom, you're logged in, no extra requests necessary. Sped up a test suite by almost 30%.

Collaborator

Closing this. I just don't think it's necessary.

@jnicklas jnicklas closed this Aug 30, 2011

Can this be reconsidered? [rspec-rails includes vendor/capybara(https://github.com/rspec/rspec-rails/commit/d0e790e9cd8d63115a6bcf523a11f56c5f1adb79), and that means hooking RSpec into Capybara "by ourselves" isn't possible.

I would also like this to be reconsidered. There are times when it would be preferable to not have the session reset after each spec.

I don't understand why you wouldn't want to give users more configuration options.

Collaborator
abotalov commented Jan 8, 2015

+1
User may want to use another mechanism to make sure that tests are relatively independent (rspec/rspec-core#1811)

z41 commented Dec 26, 2016 edited

Migrating from page-object to site-prism, getting into this issue. Monkey patching again is my tool, that's pity.

z41 commented Dec 26, 2016

One of scenarios when having such an option can really help:
I have pages with loading time about 30 seconds or even more (search results pages) and this would hardly be improved. So instead of loading the page every time I just reset its state. And the only option I have with capybara is to monkey patch it =(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment