2
votes

I was using the poltergeist has driver and had to migrate to selenium, but when the browser (Mozilla firefox 50.0.02) opens and starts doing the test case it stops in the first click event unable to proceed to the next page.

Test case (stops because don't find Add, apparently because the click method don't work)

require 'rails_helper'

feature 'creation of advices' do
  scenario'Sucessfully create an advice' do
    do_brand_login
    # find('a[href="/clients/advice_requests"]')
    page.click_link 'Requests'
    # find(:xpath,'//a[@href="/clients/advice_requests"]').trigger('click')
    click_link 'Add'

    #Primeiro passo
    find('input[id="clients_advice_request_request_type_id-selectized"]').click
    find('div[data-value="1"]').click

    find('input[id="clients_advice_request_contact_ids-selectized"]').click
    first('div[class^="option"]').click

    find('input[id="clients_advice_request_po_id-selectized"]').click
    find('div[data-value="3"]').click

    find('input[id="clients_advice_request_lead_contact_id-selectized"]').click
    first('div[class^="option"]').click

    fill_in 'Your reference', with: 'Valkyre'
    fill_in 'Campaign name', with: 'Mjolnir for everyone'
    fill_in 'Advertised product/service', with: 'Mjolnir'

    click_button 'Next'
    #Segundo passo
    expect(page).to have_content "Details"
    # find('textarea[id="clients_advice_request_instructions"]').send_keys('Put yout hammer here')

    fill_in 'Instructions', with: 'Put yout hammer here'

    first('.icheckbox_flat').click
    # click 'Do you require an estimate?'
    find('.bootstrap-switch').click
    fill_in 'By when do you require the estimate?', with: 2.days.from_now
    fill_in 'By when do you require the advice?', with: 2.days.from_now
    find('input[id="clients_advice_request_trademark_search_id-selectized"]').click
    page.find('div[class="option"]', text: 'No').click
    find('input[id="clients_advice_request_country_ids-selectized"]').click
    find('div[data-value="1"]').click
    find('div[data-value="2"]', text: 'Austria').click

    click_button 'Next'

    #Terceiro passo
    drop_in_dropzone Rails.root.join('public/favicon.ico')


    # wait_for_ajax
    # click_button 'Next'
    # wait_for_ajax
    expect(page).to have_content "Review materials can't be blank"
    find('button[class="btn btn-primary btn-icon icon-right"]').click
    # drop_in_dropzone Rails.root.join('public/favicon.ico')

    puts current_url
    require 'pry'; binding.pry
    expect(page).to have_content "Ovewview"
    #Quarto passo
    click_button 'Submit'
  end
end

Rails helper

# This file is copied to spec/ when you run 'rails generate rspec:install'
ENV['RAILS_ENV'] ||= 'test'
require File.expand_path('../../config/environment', __FILE__)
# Prevent database truncation if the environment is production
abort("The Rails environment is running in production mode!") if Rails.env.production?
require 'spec_helper'
require 'rspec/rails'
require 'capybara/rails'
Dir[Rails.root.join("spec/support/**/*.rb")].each {|f| require f}
# Add additional requires below this line. Rails is not loaded until this point!
require "selenium-webdriver"

# Requires supporting ruby files with custom matchers and macros, etc, in
# spec/support/ and its subdirectories. Files matching `spec/**/*_spec.rb` are
# run as spec files by default. This means that files in spec/support that end
# in _spec.rb will both be required and run as specs, causing the specs to be
# run twice. It is recommended that you do not name files matching this glob to
# end with _spec.rb. You can configure this pattern with the --pattern
# option on the command line or in ~/.rspec, .rspec or `.rspec-local`.
#
# The following line is provided for convenience purposes. It has the downside
# of increasing the boot-up time by auto-requiring all files in the support
# directory. Alternatively, in the individual `*_spec.rb` files, manually
# require only the support files necessary.
#
# Dir[Rails.root.join('spec/support/**/*.rb')].each { |f| require f }

# Checks for pending migration and applies them before tests are run.
# If you are not using ActiveRecord, you can remove this line.
ActiveRecord::Migration.maintain_test_schema!

RSpec.configure do |config|
  # Remove this line if you're not using ActiveRecord or ActiveRecord fixtures
  config.fixture_path = "#{::Rails.root}/spec/fixtures"
  config.include LoginHelper
  config.include DropZoneHelper

  # If you're not using ActiveRecord, or you'd prefer not to run each of your
  # examples within a transaction, remove the following line or assign false
  # instead of true.
  config.use_transactional_fixtures = true

  # RSpec Rails can automatically mix in different behaviours to your tests
  # based on their file location, for example enabling you to call `get` and
  # `post` in specs under `spec/controllers`.
  #
  # You can disable this behaviour by removing the line below, and instead
  # explicitly tag your specs with their type, e.g.:
  #
  #     RSpec.describe UsersController, :type => :controller do
  #       # ...
  #     end
  #
  # The different available types are documented in the features, such as in
  # https://relishapp.com/rspec/rspec-rails/docs
  config.infer_spec_type_from_file_location!

  # Filter lines from Rails gems in backtraces.
  config.filter_rails_from_backtrace!
  # arbitrary gems may also be filtered via:
  # config.filter_gems_from_backtrace("gem name")
end

spec_helper

require 'capybara/rspec'
require 'capybara/dsl'
# require 'capybara/poltergeist'
Capybara.default_max_wait_time = 30
Capybara.configure do |c|
  c.javascript_driver = :selenium
  c.default_driver = :selenium
  c.app_host = "http://www.192.168.0.25.xip.io:3001"
end

# This file was generated by the `rails generate rspec:install` command. Conventionally, all
# specs live under a `spec` directory, which RSpec adds to the `$LOAD_PATH`.
# The generated `.rspec` file contains `--require spec_helper` which will cause
# this file to always be loaded, without a need to explicitly require it in any
# files.
#
# Given that it is always loaded, you are encouraged to keep this file as
# light-weight as possible. Requiring heavyweight dependencies from this file
# will add to the boot time of your test suite on EVERY test run, even for an
# individual file that may not need all of that loaded. Instead, consider making
# a separate helper file that requires the additional dependencies and performs
# the additional setup, and require it from the spec files that actually need
# it.
#
# The `.rspec` file also contains a few flags that are not defaults but that
# users commonly want.
#
# See http://rubydoc.info/gems/rspec-core/RSpec/Core/Configuration
RSpec.configure do |config|
  # rspec-expectations config goes here. You can use an alternate
  # assertion/expectation library such as wrong or the stdlib/minitest
  # assertions if you prefer.

  config.expect_with :rspec do |expectations|
    # This option will default to `true` in RSpec 4. It makes the `description`
    # and `failure_message` of custom matchers include text for helper methods
    # defined using `chain`, e.g.:
    #     be_bigger_than(2).and_smaller_than(4).description
    #     # => "be bigger than 2 and smaller than 4"
    # ...rather than:
    #     # => "be bigger than 2"
    expectations.include_chain_clauses_in_custom_matcher_descriptions = true
  end

  # rspec-mocks config goes here. You can use an alternate test double
  # library (such as bogus or mocha) by changing the `mock_with` option here.
  config.mock_with :rspec do |mocks|
    # Prevents you from mocking or stubbing a method that does not exist on
    # a real object. This is generally recommended, and will default to
    # `true` in RSpec 4.
    mocks.verify_partial_doubles = true
  end

  # This option will default to `:apply_to_host_groups` in RSpec 4 (and will
  # have no way to turn it off -- the option exists only for backwards
  # compatibility in RSpec 3). It causes shared context metadata to be
  # inherited by the metadata hash of host groups and examples, rather than
  # triggering implicit auto-inclusion in groups with matching metadata.
  config.shared_context_metadata_behavior = :apply_to_host_groups

# The settings below are suggested to provide a good initial experience
# with RSpec, but feel free to customize to your heart's content.
=begin
  # This allows you to limit a spec run to individual examples or groups
  # you care about by tagging them with `:focus` metadata. When nothing
  # is tagged with `:focus`, all examples get run. RSpec also provides
  # aliases for `it`, `describe`, and `context` that include `:focus`
  # metadata: `fit`, `fdescribe` and `fcontext`, respectively.
  config.filter_run_when_matching :focus

  # Allows RSpec to persist some state between runs in order to support
  # the `--only-failures` and `--next-failure` CLI options. We recommend
  # you configure your source control system to ignore this file.
  config.example_status_persistence_file_path = "spec/examples.txt"

  # Limits the available syntax to the non-monkey patched syntax that is
  # recommended. For more details, see:
  #   - http://rspec.info/blog/2012/06/rspecs-new-expectation-syntax/
  #   - http://www.teaisaweso.me/blog/2013/05/27/rspecs-new-message-expectation-syntax/
  #   - http://rspec.info/blog/2014/05/notable-changes-in-rspec-3/#zero-monkey-patching-mode
  config.disable_monkey_patching!

  # Many RSpec users commonly either run the entire suite or an individual
  # file, and it's useful to allow more verbose output when running an
  # individual spec file.
  if config.files_to_run.one?
    # Use the documentation formatter for detailed output,
    # unless a formatter has already been configured
    # (e.g. via a command-line flag).
    config.default_formatter = 'doc'
  end

  # Print the 10 slowest examples and example groups at the
  # end of the spec run, to help surface which specs are running
  # particularly slow.
  config.profile_examples = 10

  # Run specs in random order to surface order dependencies. If you find an
  # order dependency and want to debug it, you can fix the order by providing
  # the seed, which is printed after each run.
  #     --seed 1234
  config.order = :random

  # Seed global randomization in this process using the `--seed` CLI option.
  # Setting this allows you to use `--seed` to deterministically reproduce
  # test failures related to randomization by passing the same `--seed` value
  # as the one that triggered the failure.
  Kernel.srand config.seed
=end
end

Login Helper

module LoginHelper
  def do_brand_login
    visit 'http://yggdrasil.192.168.0.25.xip.io:3001/users/sign_in'
    fill_in 'user_email', with: '[email protected]'
    fill_in 'user_password', with: '3dfosfey'
    click_button 'Log in'
  end
end
1
What exactly is the error you get?Thomas Walpole
1) creation of advices Sucessfully create an advice Failure/Error: click_link 'Add' Capybara::ElementNotFound: Unable to find link "Add"João Vitor
Are you sure there is a link with text of "Add" on the page? Add sleep 3; puts page.html after the Requests click and make sure the page is what you expect it to beThomas Walpole
The real problem is that when the browser is supposed to click the Request it never happens, and i already tried multiple forms to do it but no one solves the problem. But if I go and manually click in the button it sends me to the desired page, and this only method that don't work, just don't work in selenium, when i used poltergeist it worked just fine.João Vitor
Have you looked at your test.log to see if a request comes from the Request click? Normally if the Request click didn't do anything it would cause an error. One other potential issue is your do_brand_login method. If it doesn't have an expectation at the end that waits for the login to complete then your clicks may occur before the login has actually been processed. What does do_brand_login look like?Thomas Walpole

1 Answers

1
votes

There is no guarantee that click_button/click_link/click etc, will wait for the actions the click triggers to complete. Because of that you need to make Capybara wait after triggering the action for it to complete, by expecting whatever visible change the action triggers. Without that a second click following the first will attempt to click immediately after the first click if an element that matches already exists on the first page. This can end up canceling the first click, interrupting its action, or just randomly causing clicks to look like they're ignored. In your case you login helper do_brand_login should be specifically expecting something at the end that indicates the login has completed - something like

expect(page).to have_content("You are now logged in!") # Or whatever content is shown