Tag Archives: capybara

Updating Chromedriver when system chrome is updated

by about , , ,

I use Capybara for testing, with chrome extension. From time to time Ubuntu asks to update chrome to a newest version. This breaks compatibilty with chromedriver version for testing purposes.

You experienced an error like this:

In this link you have all webdriver versions matching with your actual browser version.

I downloaded and installed to solve the problem. Here the commands:

wget https://edgedl.me.gvt1.com/edgedl/chrome/chrome-for-testing/116.0.5845.96/linux64/chromedriver-linux64.zip
unzip chromedriver-linux64.zip
sudo mv chromedriver-linux64/chromedriver /usr/local/bin/
sudo chown root:root /usr/local/bin/chromedriver
sudo chmod +x /usr/local/bin/chromedriver
rm -r chromedriver*

Hope it workd for you.

Happy coding!!

Capybara wait and timeout options

by about , ,

I usually use Rspec with Capybara, in order to create feature tests. These test views with a real browser. And sometimes we have triggering timeouts, and random failures in tests, due to slow javascripts executions, random load in test cases ….

11 years ago now, Jonas Nicklas, Capybara’s leader, removed wait_until from the code. Basically it introduced an abuse of this clause in our tests, and random execution times. Here you can read some well explained reasons, with the basic recommendatio to reasearch why are happenning these timeouts instead of waiting long times in your test suites. Delay can be huge when you have a good amount of tests.

But Capybara introduced some wait clauses tha I will explain below….

You can increate wait time in capybara assertions at `spec/rails_helper.rb`:

Capybara.default_max_wait_time = 10 # default is 2

Sometimes developers use `sleep 0.5` on their code. Problem here is that they are fixed waits, opposite than ‘wait’ or ‘wait_until’ which exit when a condition is achieved.

As alternative wyou can use `wait:` options in all contions like `have_….`:

expect(page).to have_text(I18n.t('investments.sale_movements.form.title'), wait: 20)

This option waits the amount of 20 second, then, fails:

In case you are not using a Capybara assertion, you can use the following block:

using_wait_time 60 do
  expect(Organization.find_by(subdomain: organization.subdomain)).to be_present
end

These two last cases modify the default time inculded in configuration file.

This does not remove all failures, but it improves legibility. And you can check in tests logs if test is failing by a timeout or antother reason.

Happy coding!!!

Smoke production tests for critical features

by about , , , ,

Use case:

  • A client wants to be sure that some critical functionality is running in their production environments. Example: their products are showing in their web shop.

Plan:

  • Create some Smoke tests against production server
  • Create a Jenkins job which executes them every hour, sending a mail if this fails

In this post we will see how to create these Smoke tests with Rspec/Capybara/Mechanize. On server you can have deployed whatever web technology (Java, PHP, Node …). Required gems:

  • Rspec: testing Ruby environment
  • Capybara: simple DSL for simulating user interaction with a web application
  • Capibara-mechanize: Capybara driver which uses mechanize to create remote server requests

So that in your Gemfile (asuming you use Bundler to manage your dependencies):

  gem 'capybara'
  gem 'capybara-mechanize'

The specification:

require 'spec_helper'
 
WEBSITE_URL = "http://www.swordshop.com"
 
feature "Critical features on: #{WEBSITE_URL}" , smoke: true do
  background do
    Capybara.run_server = false
    Capybara.app_host = WEBSITE_URL
    require 'capybara/mechanize'
    Capybara.default_driver = :mechanize
 
    visit root_path
  end
 
  scenario "root is up" do
    page.should have_content("Best Swords in the world")
  end
 
  scenario "products url is showing products" do
    within("nav") { click_on "Products" }
    page.should have_css(".product")
  end
end

Just a little great detail: include smoke tag in your excluding filters, so that this will not be mixed with your unit and functional tests:

  config.filter_run_excluding :smoke

And you can allways call these tests with the command:

rspec --tag smoke