Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Twilio Test Toolkit overwrites current page for Capybara feature tests #7

Open
pjungwir opened this issue Jun 28, 2013 · 4 comments
Open

Comments

@pjungwir
Copy link

Thank you for this gem; it is really useful!

I have a Capybara feature test where the user visits a couple pages, then receives a call from Twilio to enter a PIN, then clicks another button on the web site. So I have a test script that looks like this:

fill_in "Foo"
click_on "Next"
call = ttt_call(bar)
call.within_gather do |g|
  # ...
end
click_on "Activate"

Unfortunately ttt_call appears to be overwriting Capybara's current page. If I look at page.html before using ttt_call, I see the Activate button, but if I look at page.html after doing the call, it now returns the TwiML from the last Twilio interaction. Similarly, methods like click_on and fill_in now search the TwiML, not the HTML from the current web page. Any idea how I can include ttt_call inside a longer feature test, where the user clicks on web pages before and after the call?

@JMongol
Copy link
Owner

JMongol commented Jun 29, 2013

Hey Paul,

Glad to hear you are finding TTT useful!

The behavior you describe is definitely by design, in that ttt_call is intentionally hijacking Capybara's session to pretend to be an HTTP request from Twilio. That said, you do present what I consider to be a valid test case, so we should consider how to support this.

A couple of initial thoughts spring to mind. One such option is that we could avoid using Capybara for the HTTP request entirely, although it's unclear how much work that would be and what side effects that would introduce. Perhaps a less invasive option would be to create some type of Capybara session stack, in which we push the current session to the stack when ttt_call is invoked, and pop it when your call is completed.

Depending on your situation, an interim workaround could be to force Capybara to visit your page again when your call is completed, thus updating the session. It depends on how your application is built though, and it admittedly isn't a very good workaround for some apps and scenarios.

Let me chew on it a bit. If you have other thoughts or implementation ideas, feel free to leave them here.

Jack

@pjungwir
Copy link
Author

Thanks for such a thoughtful response.

I don't know about ease of implementation, but a nice API would be to scope ttt_call's changes to a block--something like this:

visit some_path
ttt_call(foo) do |call|
  call.should have_say("...")
end
click_on "Next"

This is pretty much just a nice way of packaging your suggestion for a Capybara stack.

@maxhawkins
Copy link

I just ran into this problem as well.

Capybara actually has a mechanism to solve this problem. You can set Capybara.session_name and the next request will be sent from the specified session.

Another way is to generate a Capybara::Session for each CallInProgress or one shared between them.

Whatever way you choose, it would be nice if the session was externally accessible/set table. That way you could choose to share or not share based on the application.

@JMongol
Copy link
Owner

JMongol commented Aug 6, 2013

Thanks for the info Max.

At the moment I'm slammed with other projects, so if someone would like to generate a pull request (with accompanying tests) for this, I'll be happy to have a look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants