Tag Archives: ruby

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

Configuration Management

by about , ,

We create Ruby on Rails Web Applications, mainly in several environments, so that is really important not only the automated Deployment for us, but the automated installation (Configuration) also. For Server side, we use dedicated Ubuntu LTS Systems, on the usual providers: AWS, DO, Linode …

We use Capistrano for automated deployments, and we searched years ago for a tool for Configuration Management. We were evaluating all market possibilities: Chef, Puppet, Salt, Ansible …. And finally we decided Chef for a reason: We know ruby so writing recipes in ruby was a big advantage.

But working with Chef Solo we found several limitations:

  • Need to install Chef Agent in node, which makes the process heavy.
  • You need to run all tasks on every setup command, it delays debugging tasks.
  • Debugging errors are a hell, there is not a clear help for errors. Indeed the documentation is sometimes poor.

Probably regarding that situation Ansible server agent-less promise would be the best option. But I found several inconveniences:

  • Language based on YAML, really verbose (try to install a big list of packages)
  • We would lose ruby for writing recipes.
  • Working with environments/roles is not really standardized.

What do we really need?

  • Write recipes (scripts) in Ruby, in our well-known and loved language.
  • Agent-less server side. Solve everything with an ssh connection.
  • Work with variables.
  • Work with environment/roles variables and configurations.
  • Work with templates for configuration files.

Chef, Ansible, Salt … Are really powerful, but:

  • Do we need OS compatibility? No, we use Ubuntu LTS versions.
  • Do we need complicated idioms? No, we have ruby and Shell scripts.
  • Do we need Warehouses or Galaxies of recipes? well … yes, they are useful, but sometimes they are solved with a shell script.

Sometimes, the solution is the easiest way. Shell scripting ? near, but what about ruby, variables or templates …. Capistrano 3:

  • Based on Ruby rake tasks.
  • Only SSH connections, based on SSHkit.
  • Working with roles, environments and variables out of the box.
  • We know the tool because our deployments are based on this.
  • We will integrate the standard recipes into our prun-ops gem.

Yes, we need templates, but we have ERB in Ruby, and googling a while we can find an easy solution for templating.

Today our analysis gives Capistrano 3 as the best way to go, tomorrow … who knows?