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

Already on GitHub? Sign in to your account

Add async javascript support for open_email and friends #18

Closed
mikegrassotti opened this Issue Feb 8, 2013 · 8 comments

Comments

Projects
None yet
5 participants

When testing a single page js app with capybara 2 it's finders are smart enough to wait for an element, up to Capybara.default_wait_time. This is important since the elements to be tested are often loaded asynchronously.

The same is true for open_email. For example: Testing password reset form. User fills out a form, hits submit then we want to open email and verify contents. The submit triggers ajax, capybara test moves on and attempts to open email before it has been sent by the server:

fill_in 'Email', :with => 'guest@example.com'
click_on "Submit"
open_email('guest@example.com')
# FAIL!

As a workaround i have done the following:

click_on "Submit"
# Make sure we wait for this confirm before moving on with test!
page.should have_content 'A reset password email has been sent to you.'
open_email('guest@example.com')

I've not looked at capybara implementation but perhaps it is possible to applying the same strategy that is used there?

Contributor

bcardarella commented Feb 8, 2013

Does that make sense? I thought javascript wasn't allowed in emails

Contributor

bcardarella commented Feb 8, 2013

Oh, I read that wrong. You are kicking off the email from an AJAX action on the app. Yes, this makes sense.

@ghost ghost assigned bcardarella Feb 8, 2013

Contributor

bcardarella commented Jul 12, 2013

Sorry it took so long to tackle this. We have decided the best way to handle this is to force a sleep for a short period of time, maybe 1/10th of a second before the open_email event.

The reason is because it is undeterministic if we expect an email to be in the inbox or if we expect a new email. Given the scenario of existing emails and I kick off a JavaScript event that sends an email it is not determined if the top email is the one I want or not. We could always force a sleep but that would punish users who aren't dealing with this issue. It's not ideal but it is the best work-around we can think of.

YSavir commented Apr 27, 2016

Just had this happen... I really hate having to throw in a random sleep into my code along with a comment to qualify it. Would it be possible to add a wait: <integer> parameter to open_email, with wait defaulting to 0 seconds?

If that is viable, I would be happy to submit a PR.

Collaborator

andrewhavens commented Apr 28, 2016

@YSavir I think the sleep should be built in. I think open_email will normally return immediately (so most people wouldn't see a delay), but in the times that an email could not be found, it should sleep for a short time, then try again up to a maximum of 3 seconds (or a configurable max wait time). Can you submit a PR for this? I would be happy to review and merge.

YSavir commented Apr 28, 2016

@andrewhavens Sure thing! Will get one in this weekend.

it should sleep for a short time, then try again up to a maximum of 3 seconds (or a configurable max wait time)

I think it would be intuitive for this to use Capybara.default_max_wait_time, rather than introducing a new config variable, so it works with using_wait_time.

YSavir commented Apr 29, 2016

@jezstephens Yep, was planning on using that. This is, after all, Capybara-Email, and I'd rather keep true to it's name. :)

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