Open pjungwir opened 11 years ago
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
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.
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.
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.
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:
Unfortunately ttt_call appears to be overwriting Capybara's current page. If I look at
page.html
before usingttt_call
, I see the Activate button, but if I look atpage.html
after doing the call, it now returns the TwiML from the last Twilio interaction. Similarly, methods likeclick_on
andfill_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?