calebhearth / formulaic

Simplify form filling with Capybara

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Does not support multiple capybara sessions

ryanong opened this issue · comments

We inherited the experience pattern from thoughtbot NYC. It is pretty fantastic.

We made a small modification in some of the experiences so we can handle multiple sessions.

class StudentExperience < Experience
  def page
    @page || begin
      Capybara.using_session(:student) do
        @page = Capybara.current_session
      end
    end
  end
end

This would allow this specific experience to have it's own session so we could go back and form between two different roles without having to use Capybara.using_session

However by default formulaic uses Capybara.current_session so if we were to use fill_form inside an experience it breaks because it looks at the wrong session.

I am willing to put in the work make formulaic work with this pattern but I need some guidance in how you wish this to be coded. Specifically do you want this passed down be default in the DSL#fill_form then in the Input just execute all actions off the passed down session?

It seems like a smell to pass the session all the way down but I can't figure out a better way to do it.

I'm fairly convinced against multiple sessions being a good idea, so I'm not sure formulaic should support this.

Could you clarify why it isn't a good idea?

Sure. My experiences with it have been that it slows things down (by requiring another Capybara stack to be spun up, exasperated when using capybara-webkit, selenium, &c. since they are even more memory and computationally expensive), that their benefit is negligible over a backdoor or even just signing out and back in, and that they confuse me since I'm never sure which session I'm "in".

Capybara is clearly not meant to be used in this way, as well, else we'd not need to "work around" Capybara.current_session like you recommend.

You are right that it slows things down. But we need to check state in an open session (ember) and there is no real way around it.

We actually moved from using the current session hack to using the BBQ session pool. (ripped it out and just used it in our code)
https://github.com/drugpl/bbq/blob/master/lib/bbq/session.rb

By attaching the session to an experience you never have to worry about which session you are in either because you are executing all commands against the experience.

student_ux = StudentExperience.new
student_ux.visit_edit_activity
student_ux.fill_out_form
student_ux.submit_form
expect(student_ux).to have_content "Activity successfully updated"

However, I understand your point of view. Thanks for the explanation! Hope things are well up north! (besides being cold and all)

I'll just monkey patch it locally to support multiple sessions.

I actually relocated to Austin, so it's a bit rainy but nice weather. In San Diego today which is even nicer!

Man, now you are just making me jealous.