rspec-rails-examples icon indicating copy to clipboard operation
rspec-rails-examples copied to clipboard

Failure on native date input on subscribing user to newsletter

Open leesmith opened this issue 9 years ago • 18 comments

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
>$

leesmith avatar Jun 11 '15 20:06 leesmith

@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?

eliotsykes avatar Jun 14 '15 16:06 eliotsykes

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

leesmith avatar Jun 15 '15 14:06 leesmith

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 avatar Jul 06 '15 06:07 leesmith

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.

leesmith avatar Jul 22 '15 16:07 leesmith

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 avatar Jul 23 '15 10:07 eliotsykes

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

eliotsykes avatar Jul 23 '15 11:07 eliotsykes

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 avatar Jul 23 '15 12:07 eliotsykes

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 avatar Jul 23 '15 14:07 eliotsykes

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 avatar Jul 23 '15 14:07 eliotsykes

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: https://github.com/travis-ci/travis-ci/issues/938#issuecomment-90791432

eliotsykes avatar Jul 23 '15 14:07 eliotsykes

When bringing chrome back, see capybara.rb:

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

eliotsykes avatar Jul 23 '15 14:07 eliotsykes

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 avatar Jul 23 '15 14:07 eliotsykes

@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.

eliotsykes avatar Jul 23 '15 14:07 eliotsykes

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!

leesmith avatar Jul 23 '15 19:07 leesmith

@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

amnesia7 avatar Sep 02 '15 21:09 amnesia7

@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.

eliotsykes avatar Sep 03 '15 06:09 eliotsykes

@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?

amnesia7 avatar Sep 04 '15 20:09 amnesia7

@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.)

eliotsykes avatar Sep 05 '15 09:09 eliotsykes