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

Failure on native date input on subscribing user to newsletter #70

Open
leesmith opened this issue Jun 11, 2015 · 18 comments
Open

Failure on native date input on subscribing user to newsletter #70

leesmith opened this issue Jun 11, 2015 · 18 comments

Comments

@leesmith
Copy link

I'm on OSX 10.10.3, Firefox 38.0.5. It looks like the date input is not being recognized and falling back to today's date, which is not what the test is expecting.

$> rake
...snip...
Failures:

  1) Subscribe to newsletter in browser with native date input subscribes user to newsletter
     Failure/Error: expect(page).to be_confirm_subscription_page(Subscription.last)

       expected content: Your subscription will start on January 1st, 2015, thank you!
            got content: Your subscription will start on June 11th, 2015, thank you!
     # ./spec/features/subscribe_to_newsletter_spec.rb:21:in `block (4 levels) in <top (required)>'
     # ./spec/features/subscribe_to_newsletter_spec.rb:18:in `block (3 levels) in <top (required)>'

Finished in 32.53 seconds (files took 3.14 seconds to load)
73 examples, 1 failure

Failed examples:

rspec ./spec/features/subscribe_to_newsletter_spec.rb:7 # Subscribe to newsletter in browser with native date input subscribes user to newsletter

Randomized with seed 24965

/Users/lsmith/.rbenv/versions/2.2.2/bin/ruby -I/Users/lsmith/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/rspec-core-3.2.3/lib:/Users/lsmith/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/rspec-support-3.2.2/lib /Users/lsmith/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/rspec-core-3.2.3/exe/rspec --pattern spec/\*\*\{,/\*/\*\*\}/\*_spec.rb failed
>$
eliotsykes added a commit that referenced this issue Jun 14, 2015
…8.0.5

Try Travis CI build with latest firefox 38.0.5, attempt at replicating bug #70
@eliotsykes
Copy link
Owner

@leesmith I think that particular failing spec ran against PhantomJS - do you happen to know what version of PhantomJS you've got installed in this environment?

@leesmith
Copy link
Author

I'm using phantomJS 2.0.0...as installed via Homebrew for OSX.

@leesmith
Copy link
Author

leesmith commented Jul 6, 2015

I don't guess you were able to replicate this?

So for this specific test, when I inspect the params in the create action of the subscriptions controller, "Start date" is not being set to what the test code is trying to set it to (Jan. 1st). I always get today's date on the controller side, which I'm guessing is the default value for that form field...

@leesmith
Copy link
Author

Is there a reason you're specifically using selenium-webdriver? Doesn't poltergeist run a headless webkit browser in the background? Wouldn't that be preferred over the selenium/firefox combo?

This test still fails for me, btw.

@eliotsykes
Copy link
Owner

Apologies for being slow to respond to this.

There's a couple reasons using both a headless and real browser:

  1. Showing a real browser being driven on a student's screen by a spec is a good way to introduce the subject. It makes it concrete as to what's going on when a feature spec is run and is just more satisfying and fun.
  2. Running multiple capybara drivers serves as a demonstration of how its done with the driver: ... meta data

I've got some time now to try replicating the issue, I'm on an older phantomjs currently so that might explain the difference.

@eliotsykes
Copy link
Owner

Tried the spec in phantomjs 1.9.8 (brew install phantomjs) on Mac 10.9.5 & passes. Next up phantomjs 2...

@eliotsykes
Copy link
Owner

Homebrew needed updating:

brew update
brew upgrade phantomjs

Now phantomjs 2.0.0 is installed and replicating the failure!

$ bin/rspec spec/features/subscribe_to_newsletter_spec.rb 

Randomized with seed 13245

Subscribe to newsletter
  in browser without native date input
    subscribes user to newsletter
  in browser with native date input
    subscribes user to newsletter (FAILED - 1)

Failures:

  1) Subscribe to newsletter in browser with native date input subscribes user to newsletter
     Failure/Error: expect(page).to be_confirm_subscription_page(Subscription.last)

       expected content: Your subscription will start on January 1st, 2015, thank you!
            got content: Your subscription will start on July 23rd, 2015, thank you!
     # ./spec/features/subscribe_to_newsletter_spec.rb:21:in `block (4 levels) in <top (required)>'
     # ./spec/features/subscribe_to_newsletter_spec.rb:18:in `block (3 levels) in <top (required)>'
     # -e:1:in `<main>'

Finished in 21.85 seconds (files took 0.49821 seconds to load)
2 examples, 1 failure

Failed examples:

rspec ./spec/features/subscribe_to_newsletter_spec.rb:7 # Subscribe to newsletter in browser with native date input subscribes user to newsletter

@eliotsykes
Copy link
Owner

Using Modernizr to test if phantomjs supports native date input:

      visit "https://modernizr.github.io/Modernizr/test/index.html"
      expect(page).to have_css("#date", text: "date: true")
      save_and_open_page

I've wrongly had the CapybaraDriverResolver configured to treat phantomjs as a browser with native date inputs. It doesn't seem to support native date inputs in any version I've tested (phantomjs 1.8.1, 1.9.8, 2.0.0).

I'm not sure why the test was passing with 1.8.1 and 1.9.8. Regardless, the test with those browsers is misleading. It claims to test native date inputs but it is not.

Chrome supports native date inputs so this I'm thinking chrome ought to be brought back into the project and used in this test.

@eliotsykes
Copy link
Owner

Forgot to mention, this also signifies the test for native date input support in date-input.js isn't comprehensive. It should borrow/use Modernizr's more comprehensive check.

@eliotsykes
Copy link
Owner

When bringing Chrome back into the project, it'll also need to be configured on TravisCI. There appears to be a way now for this to work. At least here's one option: travis-ci/travis-ci#938 (comment)

@eliotsykes
Copy link
Owner

When bringing chrome back, see capybara.rb:

Capybara.register_driver :chrome do |app|
  Capybara::Selenium::Driver.new(app, :browser => :chrome)
end

@eliotsykes
Copy link
Owner

In addition bring back chromedriver:

diff --git a/Gemfile b/Gemfile
index db98b95..e284699 100644
--- a/Gemfile
+++ b/Gemfile
@@ -14,7 +14,7 @@ gem 'uglifier', '>= 1.3.0'
 group :development, :test do
   gem 'byebug' # Call 'byebug' in code to stop execution and get a debugger console
   gem 'capybara'
-  # gem 'chromedriver-helper' # helps with using Chrome in feature specs
+  gem 'chromedriver-helper' # helps with using Chrome in feature specs
   gem 'factory_girl_rails', '~> 4.5'
   gem 'pry'
   gem 'pry-rails'

@eliotsykes
Copy link
Owner

@leesmith Thanks for bringing this to my attention and sorry it's taken a while to get round to digging in. I'm not sure when I'll get a chance to fix it I'm afraid.

@leesmith
Copy link
Author

No problem! This is quite a tricky test to accomplish I guess since browsers handle native date inputs differently. I've never had to test that so it's interesting to me. Great work!

@amnesia7
Copy link

amnesia7 commented Sep 2, 2015

@eliotsykes does this mean there's currently not a suitable example of how to test features with both native and javascript-popup-style date input fields?
I was just trying to figure out how your test was working for native/non-native date input and came across this issue.
Thanks

@eliotsykes
Copy link
Owner

@amnesia7 subscribe_to_newsletter_spec.rb shows how you could test both native/non-native date inputs, though its not working at the moment :-(

To get it to work would involve configuring a browser in the project that truly does support native date input (such as Chrome), then adding that browser's driver to the start of the WITH_NATIVE_DATE_INPUT array in CapybaraDriverResolver.

@amnesia7
Copy link

amnesia7 commented Sep 4, 2015

@eliotsykes if I changed my setup to use poltergeist normally and chromedriver for native date input tests do you know how you to interact with the native date input in a test? Is there anything special about it?

@eliotsykes
Copy link
Owner

@amnesia7 My guess is that you won't be able to interact directly with clicking/tapping the native date input controls. In that case, I'd assume the native date controls work as intended and not take responsibility for testing them.

You might be able to use something like this to fill in the date:

  fill_in "Start date", with: "01/01/2015"

(If that doesn't work, it might be worth tweaking the date format in the with option to match what you see when you use the date picker.)

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