Capybara: Acceptance Test Framework for Web Applications

Capybara

Capybara helps you test web applications by simulating how a real user would interact with your app. It is agnostic about the driver running your tests and comes with Rack::Test and Selenium support built in. WebKit is supported through an external gem.

Key benefits

• No setup necessary for Rails and Rack application. Works out of the box.
• Intuitive API which mimics the language an actual user would use.
• Switch the backend your tests run against from fast headless mode to an actual browser with no changes to your tests.
• Powerful synchronization features mean you never have to manually wait for asynchronous processes to complete.

Setup

Capybara requires Ruby 2.7.0 or later. To install, add this line to your Gemfile and run bundle install:

gem 'capybara'

If the application that you are testing is a Rails app, add this line to your test helper file:

require 'capybara/rails'

If the application that you are testing is a Rack app, but not Rails, set Capybara.app to your Rack app:

Capybara.app = MyRackApp

If you need to test JavaScript, or if your app interacts with (or is located at) a remote URL, you'll need to use a different driver. If using Rails 5.0+, but not using the Rails system tests from 5.1, you'll probably also want to swap the "server" used to launch your app to Puma in order to match Rails defaults.

Capybara.server = :puma # Until your setup is working
Capybara.server = :puma, { Silent: true } # To clean up your test output

Using Capybara with Cucumber

The cucumber-rails gem comes with Capybara support built-in. If you are not using Rails, manually load the capybara/cucumber module:

require 'capybara/cucumber'
Capybara.app = MyRackApp

You can use the Capybara DSL in your steps, like so:

When /I sign in/ do
  within("#session") do
    fill_in 'Email', with: 'user@example.com'
    fill_in 'Password', with: 'password'
  end
  click_button 'Sign in'
end

You can switch to the Capybara.javascript_driver (:selenium by default) by tagging scenarios (or features) with @javascript:

@javascript
Scenario: do something Ajaxy
  When I click the Ajax link
  ...

There are also explicit tags for each registered driver set up for you (@selenium, @rack_test, etc).

Using Capybara with RSpec

Load RSpec 3.5+ support by adding the following line (typically to your spec_helper.rb file):

require 'capybara/rspec'

If you are using Rails, put your Capybara specs in spec/features or spec/system (only works if you have it configured in RSpec) and if you have your Capybara specs in a different directory, then tag the example groups with type: :feature or type: :system depending on which type of test you're writing.

If you are using Rails system specs please see their documentation for selecting the driver you wish to use.

If you are not using Rails, tag all the example groups in which you want to use Capybara with type: :feature.

You can now write your specs like so:

describe "the signin process", type: :feature do
  before :each do
    User.create(email: 'user@example.com', password: 'password')
  end

  it "signs me in" do
    visit '/sessions/new'
    within("#session") do
      fill_in 'Email', with: 'user@example.com'
      fill_in 'Password', with: 'password'
    end
    click_button 'Sign in'
    expect(page).to have_content 'Success'
  end
end

Use js: true to switch to the Capybara.javascript_driver (:selenium by default), or provide a :driver option to switch to one specific driver. For example:

describe 'some stuff which requires js', js: true do
  it 'will use the default js driver'
  it 'will switch to one specific driver', driver: :apparition
end

Capybara also comes with a built in DSL for creating descriptive acceptance tests:

feature "Signing in" do
  background do
    User.create(email: 'user@example.com', password: 'caplin')
  end

  scenario "Signing in with correct credentials" do
    visit '/sessions/new'
    within("#session") do
      fill_in 'Email', with: 'user@example.com'
      fill_in 'Password', with: 'caplin'
    end
    click_button 'Sign in'
    expect(page).to have_content 'Success'
  end

  given(:other_user) { User.create(email: 'other@example.com', password: 'rous') }

  scenario "Signing in as another user" do
    visit '/sessions/new'
    within("#session") do
      fill_in 'Email', with: other_user.email
      fill_in 'Password', with: other_user.password
    end
    click_button 'Sign in'
    expect(page).to have_content 'Invalid email or password'
  end
end

feature is in fact just an alias for describe ..., type: :feature, background is an alias for before, scenario for it, and given/given! aliases for let/let!, respectively.

Finally, Capybara matchers are also supported in view specs:

RSpec.describe "todos/show.html.erb", type: :view do
  it "displays the todo title" do
    assign :todo, Todo.new(title: "Buy milk")

    render

    expect(rendered).to have_css("header h1", text: "Buy milk")
  end
end

Note: When you require 'capybara/rspec' proxy methods are installed to work around name collisions between Capybara::DSL methods all/within and the identically named built-in RSpec matchers. If you opt not to require 'capybara/rspec' you can install the proxy methods by requiring 'capybara/rspec/matcher_proxies' after requiring RSpec and 'capybara/dsl'

Using Capybara with Test::Unit

If you are using Test::Unit, define a base class for your Capybara tests like so:

require 'capybara/dsl'

class CapybaraTestCase < Test::Unit::TestCase
  include Capybara::DSL

  def teardown
    Capybara.reset_sessions!
    Capybara.use_default_driver
  end
end

Using Capybara with Minitest

If you are using Rails system tests please see their documentation for information on selecting the driver you wish to use.

If you are using Rails, but not using Rails system tests, add the following code in your test_helper.rb file to make Capybara available in all test cases deriving from ActionDispatch::IntegrationTest:

require 'capybara/rails'
require 'capybara/minitest'

class ActionDispatch::IntegrationTest
  # Make the Capybara DSL available in all integration tests
  include Capybara::DSL
  # Make `assert_*` methods behave like Minitest assertions
  include Capybara::Minitest::Assertions

  # Reset sessions and driver between tests
  teardown do
    Capybara.reset_sessions!
    Capybara.use_default_driver
  end
end

If you are not using Rails, define a base class for your Capybara tests like so:

require 'capybara/minitest'

class CapybaraTestCase < Minitest::Test
  include Capybara::DSL
  include Capybara::Minitest::Assertions

  def teardown
    Capybara.reset_sessions!
    Capybara.use_default_driver
  end
end

Remember to call super in any subclasses that override teardown.

To switch the driver, set Capybara.current_driver. For instance,

class BlogTest < ActionDispatch::IntegrationTest
  setup do
    Capybara.current_driver = Capybara.javascript_driver # :selenium by default
  end

  test 'shows blog posts' do
    # ... this test is run with Selenium ...
  end
end

Using Capybara with Minitest::Spec

Follow the above instructions for Minitest and additionally require capybara/minitest/spec

page.must_have_content('Important!')

Drivers

Capybara uses the same DSL to drive a variety of browser and headless drivers.

Selecting the Driver

By default, Capybara uses the :rack_test driver, which is fast but limited: it does not support JavaScript, nor is it able to access HTTP resources outside of your Rack application, such as remote APIs and OAuth services. To get around these limitations, you can set up a different default driver for your features. For example if you'd prefer to run everything in Selenium, you could do:

Capybara.default_driver = :selenium # :selenium_chrome and :selenium_chrome_headless are also registered

However, if you are using RSpec or Cucumber (and your app runs correctly without JS), you may instead want to consider leaving the faster :rack_test as the default_driver, and marking only those tests that require a JavaScript-capable driver using js: true or @javascript, respectively. By default, JavaScript tests are run using the :selenium driver. You can change this by setting Capybara.javascript_driver.

You can also change the driver temporarily (typically in the Before/setup and After/teardown blocks):

Capybara.current_driver = :apparition # temporarily select different driver
# tests here
Capybara.use_default_driver       # switch back to default driver

Note: switching the driver creates a new session, so you may not be able to switch in the middle of a test.

RackTest

RackTest is Capybara's default driver. It is written in pure Ruby and does not have any support for executing JavaScript. Since the RackTest driver interacts directly with Rack interfaces, it does not require a server to be started. However, this means that if your application is not a Rack application (Rails, Sinatra and most other Ruby frameworks are Rack applications) then you cannot use this driver. Furthermore, you cannot use the RackTest driver to test a remote application, or to access remote URLs (e.g., redirects to external sites, external APIs, or OAuth services) that your application might interact with.

capybara-mechanize provides a similar driver that can access remote servers.

RackTest can be configured with a set of headers like this:

Capybara.register_driver :rack_test do |app|
  Capybara::RackTest::Driver.new(app, headers: { 'HTTP_USER_AGENT' => 'Capybara' })
end

See the section on adding and configuring drivers.

Selenium

Capybara supports Selenium 3.5+ (Webdriver). In order to use Selenium, you'll need to install the selenium-webdriver gem, and add it to your Gemfile if you're using bundler.

Capybara pre-registers a number of named drivers that use Selenium - they are:

• :selenium => Selenium driving Firefox
• :selenium_headless => Selenium driving Firefox in a headless configuration
• :selenium_chrome => Selenium driving Chrome
• :selenium_chrome_headless => Selenium driving Chrome in a headless configuration

These should work (with relevant software installation) in a local desktop configuration but you may need to customize them if using in a CI environment where additional options may need to be passed to the browsers. See the section on adding and configuring drivers.

Note: drivers which run the server in a different thread may not share the same transaction as your tests, causing data not to be shared between your test and test server, see Transactions and database setup below.

Apparition

The apparition driver is a new driver that allows you to run tests using Chrome in a headless or headed configuration. It attempts to provide backwards compatibility with the Poltergeist driver API and capybara-webkit API while allowing for the use of modern JS/CSS. It uses CDP to communicate with Chrome, thereby obviating the need for chromedriver. This driver is being developed by the current developer of Capybara and will attempt to keep up to date with new Capybara releases. It will probably be moved into the teamcapybara repo once it reaches v1.0.

The DSL

A complete reference is available at rubydoc.info.

Note: By default Capybara will only locate visible elements. This is because a real user would not be able to interact with non-visible elements.

Note: All searches in Capybara are case sensitive. This is because Capybara heavily uses XPath, which doesn't support case insensitivity.

Navigating

You can use the visit method to navigate to other pages:

visit('/projects')
visit(post_comments_path(post))

The visit method only takes a single parameter, the request method is always GET.

You can get the current path of the browsing session, and test it using the have_current_path matcher:

expect(page).to have_current_path(post_comments_path(post))

Note: You can also assert the current path by testing the value of current_path directly. However, using the have_current_path matcher is safer since it uses Capybara's waiting behaviour to ensure that preceding actions (such as a click_link) have completed.

Clicking links and buttons

Full reference: Capybara::Node::Actions

You can interact with the webapp by following links and buttons. Capybara automatically follows any redirects, and submits forms associated with buttons.

click_link('id-of-link')
click_link('Link Text')
click_button('Save')
click_on('Link Text') # clicks on either links or buttons
click_on('Button Value')

Interacting with forms

Full reference: Capybara::Node::Actions

There are a number of tools for interacting with form elements:

fill_in('First Name', with: 'John')
fill_in('Password', with: 'Seekrit')
fill_in('Description', with: 'Really Long Text...')
choose('A Radio Button')
check('A Checkbox')
uncheck('A Checkbox')
attach_file('Image', '/path/to/image.jpg')
select('Option', from: 'Select Box')

Querying

Full reference: Capybara::Node::Matchers

Capybara has a rich set of options for querying the page for the existence of certain elements, and working with and manipulating those elements.

page.has_selector?('table tr')
page.has_selector?(:xpath, './/table/tr')

page.has_xpath?('.//table/tr')
page.has_css?('table tr.foo')
page.has_content?('foo')

Note: The negative forms like has_no_selector? are different from not has_selector?. Read the section on asynchronous JavaScript for an explanation.

You can use these with RSpec's magic matchers:

expect(page).to have_selector('table tr')
expect(page).to have_selector(:xpath, './/table/tr')

expect(page).to have_xpath('.//table/tr')
expect(page).to have_css('table tr.foo')
expect(page).to have_content('foo')

Finding

Full reference: Capybara::Node::Finders

You can also find specific elements, in order to manipulate them:

find_field('First Name').value
find_field(id: 'my_field').value
find_link('Hello', :visible => :all).visible?
find_link(class: ['some_class', 'some_other_class'], :visible => :all).visible?

find_button('Send').click
find_button(value: '1234').click

find(:xpath, ".//table/tr").click
find("#overlay").find("h1").click
all('a').each { |a| a[:href] }

If you need to find elements by additional attributes/properties you can also pass a filter block, which will be checked inside the normal waiting behavior. If you find yourself needing to use this a lot you may be better off adding a custom selector or adding a filter to an existing selector.

find_field('First Name'){ |el| el['data-xyz'] == '123' }
find("#img_loading"){ |img| img['complete'] == true }

Note: find will wait for an element to appear on the page, as explained in the Ajax section. If the element does not appear it will raise an error.

These elements all have all the Capybara DSL methods available, so you can restrict them to specific parts of the page:

find('#navigation').click_link('Home')
expect(find('#navigation')).to have_button('Sign out')

Scoping

Capybara makes it possible to restrict certain actions, such as interacting with forms or clicking links and buttons, to within a specific area of the page. For this purpose you can use the generic within method. Optionally you can specify which kind of selector to use.

within("li#employee") do
  fill_in 'Name', with: 'Jimmy'
end

within(:xpath, ".//li[@id='employee']") do
  fill_in 'Name', with: 'Jimmy'
end

There are special methods for restricting the scope to a specific fieldset, identified by either an id or the text of the fieldset's legend tag, and to a specific table, identified by either id or text of the table's caption tag.

within_fieldset('Employee') do
  fill_in 'Name', with: 'Jimmy'
end

within_table('Employee') do
  fill_in 'Name', with: 'Jimmy'
end

Working with windows

Capybara provides some methods to ease finding and switching windows:

facebook_window = window_opened_by do
  click_button 'Like'
end
within_window facebook_window do
  find('#login_email').set('a@example.com')
  find('#login_password').set('qwerty')
  click_button 'Submit'
end

Scripting

In drivers which support it, you can easily execute JavaScript:

page.execute_script("$('body').empty()")

For simple expressions, you can return the result of the script.

result = page.evaluate_script('4 + 4');

For more complicated scripts you'll need to write them as one expression.

result = page.evaluate_script(<<~JS, 3, element)
  (function(n, el){
    var val = parseInt(el.value, 10);
    return n+val;
  })(arguments[0], arguments[1])
JS

Modals

In drivers which support it, you can accept, dismiss and respond to alerts, confirms and prompts.

You can accept or dismiss alert messages by wrapping the code that produces an alert in a block:

accept_alert do
  click_link('Show Alert')
end

You can accept or dismiss a confirmation by wrapping it in a block, as well:

dismiss_confirm do
  click_link('Show Confirm')
end

You can accept or dismiss prompts as well, and also provide text to fill in for the response:

accept_prompt(with: 'Linus Torvalds') do
  click_link('Show Prompt About Linux')
end

All modal methods return the message that was presented. So, you can access the prompt message by assigning the return to a variable:

message = accept_prompt(with: 'Linus Torvalds') do
  click_link('Show Prompt About Linux')
end
expect(message).to eq('Who is the chief architect of Linux?')

Debugging

It can be useful to take a snapshot of the page as it currently is and take a look at it:

save_and_open_page

You can also retrieve the current state of the DOM as a string using page.html.

print page.html

This is mostly useful for debugging. You should avoid testing against the contents of page.html and use the more expressive finder methods instead.

Finally, in drivers that support it, you can save a screenshot:

page.save_screenshot('screenshot.png')

Or have it save and automatically open:

save_and_open_screenshot

Screenshots are saved to Capybara.save_path, relative to the app directory. If you have required capybara/rails, Capybara.save_path will default to tmp/capybara.

Matching

It is possible to customize how Capybara finds elements. At your disposal are two options, Capybara.exact and Capybara.match.

Exactness

Capybara.exact and the exact option work together with the is expression inside the XPath gem. When exact is true, all is expressions match exactly, when it is false, they allow substring matches. Many of the selectors built into Capybara use the is expression. This way you can specify whether you want to allow substring matches or not. Capybara.exact is false by default.

For example:

click_link("Password") # also matches "Password confirmation"
Capybara.exact = true
click_link("Password") # does not match "Password confirmation"
click_link("Password", exact: false) # can be overridden

Strategy

Using Capybara.match and the equivalent match option, you can control how Capybara behaves when multiple elements all match a query. There are currently four different strategies built into Capybara:

1. first: Just picks the first element that matches.
2. one: Raises an error if more than one element matches.
3. smart: If exact is true, raises an error if more than one element matches, just like one. If exact is false, it will first try to find an exact match. An error is raised if more than one element is found. If no element is found, a new search is performed which allows partial matches. If that search returns multiple matches, an error is raised.
4. prefer_exact: If multiple matches are found, some of which are exact, and some of which are not, then the first exactly matching element is returned.

The default for Capybara.match is :smart. To emulate the behaviour in Capybara 2.0.x, set Capybara.match to :one. To emulate the behaviour in Capybara 1.x, set Capybara.match to :prefer_exact.

Transactions and database setup

Note: Rails 5.1+ "safely" shares the database connection between the app and test threads. Therefore, if using Rails 5.1+ you SHOULD be able to ignore this section.

Some Capybara drivers need to run against an actual HTTP server. Capybara takes care of this and starts one for you in the same process as your test, but on another thread. Selenium is one of those drivers, whereas RackTest is not.

If you are using a SQL database, it is common to run every test in a transaction, which is rolled back at the end of the test, rspec-rails does this by default out of the box for example. Since transactions are usually not shared across threads, this will cause data you have put into the database in your test code to be invisible to Capybara.

Cucumber handles this by using truncation instead of transactions, i.e. they empty out the entire database after each test. You can get the same behaviour by using a gem such as database_cleaner.

Asynchronous JavaScript (Ajax and friends)

When working with asynchronous JavaScript, you might come across situations where you are attempting to interact with an element which is not yet present on the page. Capybara automatically deals with this by waiting for elements to appear on the page.

When issuing instructions to the DSL such as:

click_link('foo')
click_link('bar')
expect(page).to have_content('baz')

If clicking on the foo link triggers an asynchronous process, such as an Ajax request, which, when complete will add the bar link to the page, clicking on the bar link would be expected to fail, since that link doesn't exist yet. However Capybara is smart enough to retry finding the link for a brief period of time before giving up and throwing an error. The same is true of the next line, which looks for the content baz on the page; it will retry looking for that content for a brief time. You can adjust how long this period is (the default is 2 seconds):

Capybara.default_max_wait_time = 5

Be aware that because of this behaviour, the following two statements are not equivalent, and you should always use the latter!

# Given use of a driver where the page is loaded when visit returns
# and that Capybara.predicates_wait is `true`
# consider a page where the `a` tag is removed through AJAX after 1s
visit(some_path)
!page.has_xpath?('a')  # is false
page.has_no_xpath?('a')  # is true

First expression:

• has_xpath?('a') is called right after visit returns. It is true because the link has not yet been removed
• Capybara does not wait upon successful predicates/assertions, therefore has_xpath? returns true immediately
• The expression returns false (because it is negated with the leading !)

Second expression:

• has_no_xpath?('a') is called right after visit returns. It is false because the link has not yet been removed.
• Capybara waits upon failed predicates/assertions, therefore has_no_xpath? does not return false immediately
• Capybara will periodically re-check the predicate/assertion up to the default_max_wait_time defined
• after 1s, the predicate becomes true (because the link has been removed)
• The expression returns true

Capybara's RSpec matchers, however, are smart enough to handle either form. The two following statements are functionally equivalent:

expect(page).not_to have_xpath('a')
expect(page).to have_no_xpath('a')

Capybara's waiting behaviour is quite advanced, and can deal with situations such as the following line of code:

expect(find('#sidebar').find('h1')).to have_content('Something')

Even if JavaScript causes #sidebar to disappear off the page, Capybara will automatically reload it and any elements it contains. So if an AJAX request causes the contents of #sidebar to change, which would update the text of the h1 to "Something", and this happened, this test would pass. If you do not want this behaviour, you can set Capybara.automatic_reload to false.

Using the DSL elsewhere

You can mix the DSL into any context by including Capybara::DSL:

require 'capybara/dsl'

Capybara.default_driver = :webkit

module MyModule
  include Capybara::DSL

  def login!
    within(:xpath, ".//form[@id='session']") do
      fill_in 'Email', with: 'user@example.com'
      fill_in 'Password', with: 'password'
    end
    click_button 'Sign in'
  end
end

This enables its use in unsupported testing frameworks, and for general-purpose scripting.

Calling remote servers

Normally Capybara expects to be testing an in-process Rack application, but you can also use it to talk to a web server running anywhere on the internet, by setting app_host:

Capybara.current_driver = :selenium
Capybara.app_host = 'http://www.google.com'
...
visit('/')

Note: the default driver (:rack_test) does not support running against a remote server. With drivers that support it, you can also visit any URL directly:

visit('http://www.google.com')

By default Capybara will try to boot a rack application automatically. You might want to switch off Capybara's rack server if you are running against a remote application:

Capybara.run_server = false

Using sessions

Capybara manages named sessions (:default if not specified) allowing multiple sessions using the same driver and test app instance to be interacted with. A new session will be created using the current driver if a session with the given name using the current driver and test app instance is not found.

Named sessions

To perform operations in a different session and then revert to the previous session

Capybara.using_session("Bob's session") do
   #do something in Bob's browser session
end
 #reverts to previous session

To permanently switch the current session to a different session

Capybara.session_name = "some other session"

Using sessions manually

For ultimate control, you can instantiate and use a Session manually.

require 'capybara'

session = Capybara::Session.new(:webkit, my_rack_app)
session.within("form#session") do
  session.fill_in 'Email', with: 'user@example.com'
  session.fill_in 'Password', with: 'password'
end
session.click_button 'Sign in'

XPath, CSS and selectors

Capybara does not try to guess what kind of selector you are going to give it, and will always use CSS by default. If you want to use XPath, you'll need to do:

within(:xpath, './/ul/li') { ... }
find(:xpath, './/ul/li').text
find(:xpath, './/li[contains(.//a[@href = "#"]/text(), "foo")]').value

Alternatively you can set the default selector to XPath:

Capybara.default_selector = :xpath
find('.//ul/li').text

Capybara provides a number of other built-in selector types. The full list, along with applicable filters, can be seen at built-in selectors

Capybara also allows you to add custom selectors, which can be very useful if you find yourself using the same kinds of selectors very often. The examples below are very simple, and there are many available features not demonstrated. For more in-depth examples please see Capybaras built-in selector definitions.

Capybara.add_selector(:my_attribute) do
  xpath { |id| XPath.descendant[XPath.attr(:my_attribute) == id.to_s] }
end

Capybara.add_selector(:row) do
  xpath { |num| ".//tbody/tr[#{num}]" }
end

Capybara.add_selector(:flash_type) do
  css { |type| "#flash.#{type}" }
end

The block given to xpath must always return an XPath expression as a String, or an XPath expression generated through the XPath gem. You can now use these selectors like this:

find(:my_attribute, 'post_123') # find element with matching attribute
find(:row, 3) # find 3rd row in table body
find(:flash_type, :notice) # find element with id of 'flash' and class of 'notice'

Beware the XPath // trap

In XPath the expression // means something very specific, and it might not be what you think. Contrary to common belief, // means "anywhere in the document" not "anywhere in the current context". As an example:

page.find(:xpath, '//body').all(:xpath, '//script')

You might expect this to find all script tags in the body, but actually, it finds all script tags in the entire document, not only those in the body! What you're looking for is the .// expression which means "any descendant of the current node":

page.find(:xpath, '//body').all(:xpath, './/script')

The same thing goes for within:

within(:xpath, '//body') do
  page.find(:xpath, './/script')
  within(:xpath, './/table/tbody') do
  ...
  end
end

Configuring and adding drivers

Capybara makes it convenient to switch between different drivers. It also exposes an API to tweak those drivers with whatever settings you want, or to add your own drivers. This is how to override the selenium driver configuration to use chrome:

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

However, it's also possible to give this configuration a different name.

# Note: Capybara registers this by default
Capybara.register_driver :selenium_chrome do |app|
  Capybara::Selenium::Driver.new(app, :browser => :chrome)
end

Then tests can switch between using different browsers effortlessly:

Capybara.current_driver = :selenium_chrome

Whatever is returned from the block should conform to the API described by Capybara::Driver::Base, it does not however have to inherit from this class. Gems can use this API to add their own drivers to Capybara.

The Selenium wiki has additional info about how the underlying driver can be configured.

Gotchas:

Access to session and request is not possible from the test, Access to response is limited. Some drivers allow access to response headers and HTTP status code, but this kind of functionality is not provided by some drivers, such as Selenium.

Access to Rails specific stuff (such as controller) is unavailable, since we're not using Rails' integration testing.

Freezing time: It's common practice to mock out the Time so that features that depend on the current Date work as expected. This can be problematic on ruby/platform combinations that don't support access to a monotonic process clock, since Capybara's Ajax timing uses the system time, resulting in Capybara never timing out and just hanging when a failure occurs. It's still possible to use gems which allow you to travel in time, rather than freeze time. One such gem is Timecop.

When using Rack::Test, beware if attempting to visit absolute URLs. For example, a session might not be shared between visits to posts_path and posts_url. If testing an absolute URL in an Action Mailer email, set default_url_options to match the Rails default of www.example.com.

Server errors will only be raised in the session that initiates the server thread. If you are testing for specific server errors and using multiple sessions make sure to test for the errors using the initial session (usually :default)

If WebMock is enabled, you may encounter a "Too many open files" error. A simple page.find call may cause thousands of HTTP requests until the timeout occurs. By default, WebMock will cause each of these requests to spawn a new connection. To work around this problem, you may need to enable WebMock's net_http_connect_on_start: true parameter.

"Threadsafe" mode

In normal mode most of Capybara's configuration options are global settings which can cause issues if using multiple sessions and wanting to change a setting for only one of the sessions. To provide support for this type of usage Capybara now provides a "threadsafe" mode which can be enabled by setting

Capybara.threadsafe = true

This setting can only be changed before any sessions have been created. In "threadsafe" mode the following behaviors of Capybara change

Most options can now be set on a session. These can either be set at session creation time or after, and default to the global options at the time of session creation. Options which are NOT session specific are app, reuse_server, default_driver, javascript_driver, and (obviously) threadsafe. Any drivers and servers registered through register_driver and register_server are also global.

my_session = Capybara::Session.new(:driver, some_app) do |config|
  config.automatic_label_click = true # only set for my_session
end
my_session.config.default_max_wait_time = 10 # only set for my_session
Capybara.default_max_wait_time = 2 # will not change the default_max_wait in my_session

current_driver and session_name are thread specific. This means that using_session and using_driver also only affect the current thread.

Development

To set up a development environment, simply do:

bundle install
bundle exec rake  # run the test suite with Firefox - requires `geckodriver` to be installed
bundle exec rake spec_chrome # run the test suite with Chrome - require `chromedriver` to be installed

See CONTRIBUTING.md for how to send issues and pull requests.

Support Capybara

If you and/or your company find value in Capybara and would like to contribute financially to its ongoing maintenance and development, please visit Patreon

Need help? Ask on the mailing list (please do not open an issue on GitHub): http://groups.google.com/group/ruby-capybara

Author: Teamcapybara
Source Code: https://github.com/teamcapybara/capybara 
License: MIT license

#ruby #hacktoberfest 

What is GEEK

Buddha Community

Wondering how to upgrade your skills in the pandemic? Here's a simple way you can do it.

Corona Virus Pandemic has brought the world to a standstill.

Countries are on a major lockdown. Schools, colleges, theatres, gym, clubs, and all other public places are shut down, the country’s economy is suffering, human health is on stake, people are losing their jobs and nobody knows how worse it can get.

Since most of the places are on lockdown, and you are working from home or have enough time to nourish your skills, then you should use this time wisely! We always complain that we want some ‘time’ to learn and upgrade our knowledge but don’t get it due to our ‘busy schedules’. So, now is the time to make a ‘list of skills’ and learn and upgrade your skills at home!

And for the technology-loving people like us, Knoldus Techhub has already helped us a lot in doing it in a short span of time!

If you are still not aware of it, don’t worry as Georgia Byng has well said,

“No time is better than the present”

– Georgia Byng, a British children’s writer, illustrator, actress and film producer.

No matter if you are a developer (be it front-end or back-end) or a data scientist, tester, or a DevOps person, or, a learner who has a keen interest in technology, Knoldus Techhub has brought it all for you under one common roof.

From technologies like Scala, spark, elastic-search to angular, go, machine learning, it has a total of 20 technologies with some recently added ones i.e. DAML, test automation, snowflake, and ionic.

How to upgrade your skills?

Every technology in Tech-hub has n number of templates. Once you click on any specific technology you’ll be able to see all the templates of that technology. Since these templates are downloadable, you need to provide your email to get the template downloadable link in your mail.

These templates helps you learn the practical implementation of a topic with so much of ease. Using these templates you can learn and kick-start your development in no time.

Apart from your learning, there are some out of the box templates, that can help provide the solution to your business problem that has all the basic dependencies/ implementations already plugged in. Tech hub names these templates as xlr8rs (pronounced as accelerators).

xlr8rs make your development real fast by just adding your core business logic to the template.

If you are looking for a template that’s not available, you can also request a template may be for learning or requesting for a solution to your business problem and tech-hub will connect with you to provide you the solution. Isn’t this helpful 🙂

Confused with which technology to start with?

To keep you updated, the Knoldus tech hub provides you with the information on the most trending technology and the most downloaded templates at present. This you’ll be informed and learn the one that’s most trending.

Since we believe:

“There’s always a scope of improvement“

If you still feel like it isn’t helping you in learning and development, you can provide your feedback in the feedback section in the bottom right corner of the website.

#ai #akka #akka-http #akka-streams #amazon ec2 #angular 6 #angular 9 #angular material #apache flink #apache kafka #apache spark #api testing #artificial intelligence #aws #aws services #big data and fast data #blockchain #css #daml #devops #elasticsearch #flink #functional programming #future #grpc #html #hybrid application development #ionic framework #java #java11 #kubernetes #lagom #microservices #ml # ai and data engineering #mlflow #mlops #mobile development #mongodb #non-blocking #nosql #play #play 2.4.x #play framework #python #react #reactive application #reactive architecture #reactive programming #rust #scala #scalatest #slick #software #spark #spring boot #sql #streaming #tech blogs #testing #user interface (ui) #web #web application #web designing #angular #coronavirus #daml #development #devops #elasticsearch #golang #ionic #java #kafka #knoldus #lagom #learn #machine learning #ml #pandemic #play framework #scala #skills #snowflake #spark streaming #techhub #technology #test automation #time management #upgrade

7 Test Frameworks To Follow in 2021 for Java/Fullstack Developers

It is time to learn new test frameworks in 2021 to improve your code quality and decrease the time of your testing phase. Let’s explore 6 options for devs.

It is time to learn new test frameworks to improve your code quality and decrease the time of your testing phase. I have selected six testing frameworks that sound promising. Some have existed for quite a long time but I have not heard about them before.

At the end of the article, please tell me what you think about them and what your favorite ones are.

Robot Framework

Robot Framework is a generic open-source automation framework. It can be used for test automation and robotic process automation (RPA).

Robot Framework is open and extensible and can be integrated with virtually any other tool to create powerful and flexible automation solutions. Being open-source also means that Robot Framework is free to use without licensing costs.

The RoboFramework is a framework** to write test cases and automation processes.** It means that it may replace** your classic combo Selenium + Cucumber + Gherkins**. To be more precise, the Cucumber Gherkins custom implementation you wrote will be handled by RoboFramework and Selenium invoked below.

For the Java developers, this framework can be executed with Maven or Gradle (but less mature for the latter solution).

#java #testing #test #java framework #java frameworks #testing and developing #java testing #robot framework #test framework #2021

Top 15 Free JavaScript Frameworks for Web Applications

List of some useful JavaScript Frameworks and libraries for website, web apps, and mobile apps development, that developers should know about to make selection easier.
This article will help you understand the various types of JavaScript Framework available in the market. When it comes to choosing the best platform for you, it’s not only the number of features you need to consider but also its functionality. The ease with which it fits within your project is also an essential factor. The next step is to choose the framework that best fits your company requirements or you can select the best from the list of top web development companies to develop your product based on your requirements.

#javascript frameworks for web applications #web applications development companies #progressive javascript framework #javascript frameworks #javascript #frameworks

Top 10 Test Automation Frameworks in 2020

We are moving toward a future where everything is going to be autonomous, fast, and highly efficient. To match the pace of this fast-moving ecosystem, application delivery times will have to be accelerated, but not at the cost of quality. Achieving quality at speed is imperative and therefore quality assurance gets a lot of attention. To fulfill the demands for exceptional quality and faster time to market, automation testing will assume priority. It is becoming necessary for micro, small, and medium-sized enterprises (SMEs) to automate their testing processes. But the most crucial aspect is to choose the right test automation framework. So let’s understand what a test automation framework is.

What Is a Test Automation Framework?

A test automation framework is the scaffolding that is laid to provide an execution environment for the automation test scripts. The framework provides the user with various benefits that help them to develop, execute, and report the automation test scripts efficiently. It is more like a system that was created specifically to automate our tests. In a very simple language, we can say that a framework is a constructive blend of various guidelines, coding standards, concepts, processes, practices, project hierarchies, modularity, reporting mechanism, test data injections, etc. to pillar automation testing. Thus, the user can follow these guidelines while automating applications to take advantage of various productive results.

The advantages can be in different forms like the ease of scripting, scalability, modularity, understandability, process definition, re-usability, cost, maintenance, etc. Thus, to be able to grab these benefits, developers are advised to use one or more of the Test Automation Framework. Moreover, the need for a single and standard Test Automation Framework arises when you have a bunch of developers working on the different modules of the same application and when we want to avoid situations where each of the developers implements his/her approach towards automation. So let’s have a look at different types of test automation frameworks.

Types of Automated Testing Frameworks

Now that we have a basic idea about Automation Frameworks, let’s check out the various types of Test Automation Frameworks available in the marketplace. There is a divergent range of Automation Frameworks available nowadays. These frameworks may differ from each other based on their support to different key factors to do automation like reusability, ease of maintenance, etc.

Types of Test Automation Frameworks:

1. Module Based Testing Framework
2. Library Architecture Testing Framework
3. Data-Driven Testing Framework
4. Keyword Driven Testing Framework
5. Hybrid Testing Framework
6. Behavior Driven Development Framework

Benefits of a Test Automation Framework

Apart from the minimal manual intervention required in automation testing, there are many advantages of using a test automation framework. Some of them are listed below:

1. Faster time-to-market: Using a good test automation framework helps reduce the time-to-market of an application by allowing constant execution of test cases. Once automated, the test library execution is faster and runs longer than manual testing.
2. Earlier detection of defects: The documentation of software defects becomes considerably easier for the testing teams. It increases the overall development speed while ensuring correct functionality across areas. The earlier a defect is identified, the more cost-effective it is to resolve the issue.
3. Improved Testing efficiency: Testing takes up a significant portion of the overall development lifecycle. Even the slightest improvement of the overall efficiency can make an enormous difference to the entire timeframe of the project. Although the setup time takes longer initially, automated tests eventually take up a significantly lesser amount of time. They can be run virtually unattended, leaving the results to be monitored toward the end of the process.
4. Better ROI: while the initial investment may be on the higher side, automated testing saves organizations many a lot of money. This is due to the drop in the amount of time required to run tests, which leads to a higher quality of work. This in turn decreases the necessity for fixing glitches after release, thereby reducing project costs.
5. Higher test coverage: In test automation, a higher number of tests can be executed about an application. This leads to higher test coverage, which is a manual testing approach that would imply a massive team, limited heavily with their amount of time. An increased test coverage leads to testing more features and a better quality of the application.
6. Reusability of automated tests: The repetitive nature of test cases in test automation helps software developers to assess program reaction, in addition to the relatively easy configuration of their setup. Automated test cases can be utilized through different approaches as they are reusable.

#devops #testing #software testing #framework #automation testing #mobile app testing #test framework

Top 10 Web Application Frameworks

From a wide variety of Web Application Development Frameworks, it is eternally tough to pick the one framework that is completely satisfied with the project. Here, Top 10 Web Application Frameworks Describe in detail.

#web application frameworks #top web application frameworks #server-side web frameworks