DEV Community: Roselyne Makena

How To Use Waits In Selenium Ruby

Roselyne Makena — Mon, 23 Jan 2023 14:08:29 +0000

The wait command in Selenium Ruby is a powerful tool that allows for a high level of control over the test execution.

It is particularly useful for waiting for an element or simulating human behavior.

Examples of this might be to trigger an action on a page, wait for an element to appear and then click it, wait for some content to appear before submitting a form, or even simply wait for data to load on the backend before running any sort of tests.

This is very common when running AJAX requests, where you want to ensure the server returns the data before running the subsequent commands in the test. Using the right type and appropriate duration of waits could prevent your tests from breaking since waits in Selenium is the best way to tackle test flakiness.

I have been using waits in Selenium Ruby for many of my projects, which is why I have covered all the essential aspects of waits in Selenium Ruby as a part of this Selenium Ruby tutorial. The learnings of this blog on waits in Selenium Ruby will help you develop test code that considers the AUT’s dynamic nature.

Do you know? A credit card number generator is a coding based tool to stimulate random credit card numbers that developers or testers can use to test the functionality of web pages without using real credit card details.

Let’s get started.

Why are Waits used in Selenium?

Wait allows the developer to write tests to simulate user behavior, such as pressing a button, clicking on a link, and more. What it does is it waits for the presence (or visibility) and/or clickability of a certain element present in the DOM.

It also allows you to set up dependencies between two elements listed as targets in one statement.

You must know or guess when your target element will appear on the page.
You will have to handle possible page refreshes (potentially resulting in test failures or test flakiness).

The wait command in web testing can be used in the following ways listed below:

Do you know? CRC32B hash generator lets you quickly generate the CRC32B checksum hash from a given string. In addition, you can generate CRC32B hashes via your web browser.

Wait for the WebElement to be present

By default, Selenium Ruby waits forever for elements to appear on the page. You can use a wait function to allow the page to load in scenarios where you want to wait for an element to be present. This is particularly important when testing for elements on the page.

A scenario in which the wait command would be useful is in the LambdaTest E-Commerce Playground. For example, when logging in, it is necessary to ensure that the username and password text box elements are present before entering the credentials. Using the wait command can confirm this before proceeding with the test.

Wait for the WebElement to be visible

This is useful when you want to trigger an action of some kind but only after a certain element has been loaded onto the DOM. In this case, the wait enables quick test execution since you can ascertain that the element is now visible for your tests to begin.

To picture this in action, we can take an example of an eCommerce site that takes seconds to load the main title on the homepage. For our test to be successful, we would employ a wait to check for the visibility of that title and then proceed with the tests.

Wait for the WebElement to be clickable

Some elements need to be clickable before we can run our tests. For example, in our eCommerce example, we need to checkout but need the submit button to be visible before we can click on it.

Such a case would require using one of the wait methods to achieve a successful test.

Wait for the WebElement to complete its job

For example when you need to wait for a progress bar to load or wait for an animation that needs to run before you can proceed with testing.

To understand this better, we can take an example of an eCommerce site that takes some time to load all the items we picked onto our cart. In this case, we would use wait to ensure that the progress bar(which indicates fetching data) has been completed before we start our test assertions.

Do you know? The need to extract text from XML (eXtensible Markup Language) documents may arise for a number of reasons. One such justification is to run text analysis or natural language processing on the XML document’s content.

Wait to ensure the element is not stale

A wait method can be used to ensure that an element has not been modified and declared stale during the testing process.

It is important to note that “stale” means that an element (or its state) might have changed (or updated) after the last time you visited it. A common reason for this is automatic page refreshes or AJAX calls (or dynamic page loads). As a general rule, test logic should be designed to handle stale elements.

A scenario where the wait command would be necessary is when elements are deleted from the DOM, potentially causing a stale element exception. For example, if the session on the page becomes invalid after logging in, the previously loaded elements may no longer be present. In this case, using the wait function can refresh the page or generate a new session, depending on the requirements of the test.

Well, there are patterns you can use in Selenium Ruby to achieve this task based on the expected flow of the application under test and the expected test.

We will explore some of the scenarios by creating tests that showcase the use of different wait types to achieve our goals. Now, the question is, what types of waits should be used in your Selenium Ruby test code?

Akin to other Selenium-supported languages, Ruby (with Selenium) also supports popular wait mechanisms (i.e., Implicit wait, Explicit wait, and Fluent wait); let’s deep dive into each one of these (from a Selenium Ruby perspective).

Implicit, Explicit, and Fluent Waits in Selenium Ruby

Implicit waits are applied by default in Selenium. They apply to all elements on that page and are not selective on any particular element.

However, for Explicit waits, you must choose the element that the wait needs to be added onto and declare the required wait function before any action. Let’s glance at the main differences between implicit and explicit waits.

Run Selenium Ruby tests on 3000+ browsers.Try LambdaTest Now!

Do you know? JSON to Text Converter is a simple tool for converting JSON data to text. Convert, copy, and paste. It’s a handy tool for converting JavaScript Object Notation data to plain text for novice users or data analysts who don’t understand JSON.

Differences between Implicit and Explicit Waits in Selenium Ruby

IMPLICIT WAITS	EXPLICIT WAITS
Implicit wait time is applied to all the elements in the script.	Explicit wait time is only applied to a specific element, and it is defined by the script.
Implicit waits do not need a condition to be true for a wait to occur. When an implicit wait is executed, it will wait until the end of the data passes, no matter what is happening.	In an explicit wait, a condition must be true (or it times out) before it begins to execute.
Implicit waits are used for generally faster loading elements, but their flexibility is limited.	Explicit waits are used for slower-loading elements where flexibility is necessary.
Implicit waits are a better option when the load time of objects is not known.	Explicit waits can be applied to any object, and its load time is known.

Here are the different types of waits that can be used in your Selenium Ruby test code. For demonstration, we would be using the LambdaTest eCommerce website.

We will look at the following test cases for the tests and discuss how Selenium Ruby handles each scenario while performing Ruby automation testing.

Test Scenarios for the code demonstration:

Demonstrate how an implicit wait is applied during our tests.
Demonstrate how an explicit wait is applied to specific elements.
Demonstrate how an explicit wait is applied by adding a rescue block with a timeout.

Implicit Waits in Selenium Ruby

In Ruby, an implicit wait controls a test instance’s behavior when a test method is executed. The implicit wait will time out after a given amount of time if the current web element is unavailable in the DOM before throwing a No Such Element Exception. You can learn more about it through this blog on common Selenium Exceptions.

Implicit wait functions are non-deterministic, which means they do not apply any specific logic or pattern to determine if the page has fully loaded. But on the other hand, explicit wait functions are deterministic. For example, in the snapshot below, we are explicitly calling the wait on our driver so we can have the title load before the test can proceed.

An implicit wait is simple and may be used to perform any custom action during the waiting period. Any explicit wait command will override an implicit wait.

Let’s examine a code demonstration of implementing implicit waits in Selenium Ruby.

Note:* I’m using Ruby 3.0.3 and SeleniumWebDriver 4.1.0. If you have an older version of Ruby or SeleniumWebDrive, you can check the Ruby version by opening the terminal and typing the following.*

Getting elements from Inspect Tools for our tests

Before we look at the code demonstration, let’s look at how we get the elements from the browser to get the element names.

In the store, we will be looking at the search element, which in our tests, we have used the syntax below. You will notice that we used the :name “search.” But how did we get this name?

search_box = @my_driver.find_element(:name, “search”)

To get element names or identifiers, we use browser inspection tools. Most browsers have support for this.

Open the demo site > Right-click on the page and click inspect.

2- With the element selected, you will notice that the element panel that appears — There are the attributes for that object. Check for a suitable element that is unique to that element. It’s always recommended to use IDs if they are available on the specific element, but if not — you can use the next best unique identifier.

3- Another example is getting an XPath to use in our tests. Similarly, following steps one and 2, we can right-click and get the XPath from the browser developer tools as shown.

This mode of checking for elements will apply to all other elements in the testing process.

Now that we have seen how to inspect elements. Let’s look at the code demo for the waits we have discussed above. You can also learn about more locator strategies through this tutorial on locators in Selenium.

Syntax (Implicit Wait):

To employ an implicit wait, you need to know the amount of time you would like Selenium WebDriver to wait and then define it as a variable, as shown below.

    # Set an implicit wait time
       @my_driver.manage.timeouts.implicit_wait = 30

Demonstration: Implicit Waits in Selenium Ruby

This is an example of implicit waits in Selenium Ruby, which shows how we use implicit waits in Selenium Ruby.

require 'Selenium-webdriver'
require 'test-unit'

class EcommerceTests < Test::Unit::TestCase
 def setup
   username = "{LAMBDATEST_USERNAME}"
   accessToken = "{LAMBDATEST_ACCESS_KEY}"
   gridUrl = "hub.lambdatest.com/wd/hub"

   capabilities = {
     'LT:Options' => {
       "user" => username,
       "accessKey" => accessToken,
       "build" => "Ecommerce Wait Test v.1",
       "name" => "Ecommerce Wait Tests",
       "platformName" => "Windows 11"
     },
     "browserName" => "Firefox",
     "browserVersion" => "100.0",
   }

   @my_driver = Selenium::WebDriver.for(:remote,
                                        :url => "https://" + username + ":" + accessToken + "@" + gridUrl,
                                        :desired_capabilities => capabilities)

   @my_driver = Selenium::WebDriver.for :firefox
   @url = "https://ecommerce-playground.lambdatest.io/"

   @my_driver.get(@url)

   # Set an implicit wait time
   @my_driver.manage.timeouts.implicit_wait = 30

 end

 def test_title_should_be_your_store

   # The implicit time will apply by default. i.e 30 seconds
   assert_equal(@my_driver.title, "Your Store")
 end

 def teardown
   @my_driver.quit
 end
end

 def teardown
   @my_driver.quit
 end

end
          `

Code Walkthrough:

Let’s have a quick walkthrough on the code we have written above.

We first set up our capabilities and have our WebDriver ready by including the below.

Export your Username and Access Key in environment variables by running the following commands on the terminal:

   For Linux/macOS: 
    export LAMDATEST_USERNAME="YOUR_USERNAME"
    export LAMDATEST_ACCESS_KEY="YOUR ACCESS KEY"

    For Windows: set LT_USERNAME="YOUR_USERNAME"
    set LT_ACCESS_KEY="YOUR ACCESS KEY"

This will ensure that our variables are set up and ready for consumption by our script.

Next, on line 35, we set our implicit time to 30 seconds, as seen below.

Here, we set an implicit wait using the manage.timeouts.implicit_wait = 30 method. Selenium will wait 30 seconds for any element to be present in the DOM before throwing a Timeout error.

If the element is found before the 30 seconds are over, the test will continue as expected without any error and will not wait for the time to elapse.

Finally, on our test, we assert without additional methods since, by default, the implicit wait will be applied, as shown above.

Do you know? LambdaTest’s Random Octal Generator is a free online generator to generate random octal numbers by choosing how many digits each octal number should have and how many octal numbers to generate.

Explicit Waits in Selenium Ruby

An explicit wait will make the test do something before it times out. This is useful when you have a set time to perform your test, say, “let’s test this page for 15 seconds”. An explicit wait allows you to wait for the correct element before running a set action, like click or submit.

It is distinct from other waits as its effects are immediate, meaning it does not stop the execution of the test method when a timeout occurs. This means that any action performed after waiting for an element will still take place.

Explicit waits are very useful in testing for non-simplistic situations where you wish to define a response time to an element and enforce this response time as long as the provided condition is satisfied when it returns true.

Some of these waits on conditions are:

driver.find_element(id: “myElement”).enabled? — A clickable element is enabled.
driver.find_element(id: “myElement”).displayed? — An element is visible.
driver.find_element(id: “myElement”).text.included? — An element has particular text.
driver.switch_to.alert — An alert has been loaded.
driver.find_element(:id, ‘CheckBox’).selected? — A checkbox has been selected.
driver.find_element(:id, ‘CheckBox’).click — A click has been made.
driver.find_element(:id, ‘CheckBox’).clear — Deselect a checkbox.

Demonstration: Explicit Waits in Selenium Ruby

Let’s look at the full code demonstrating explicit waits in Selenium Ruby.

    require 'selenium-webdriver'
    require 'test-unit'

    class EcommerceTests < Test::Unit::TestCase
     def setup
       username= "{LAMBDATEST_USERNAME}"
       accessToken= "{LAMBDATEST_ACCESS_KEY}"
       gridUrl = "hub.lambdatest.com/wd/hub"

       capabilities = {
         'LT:Options' => {
           "user" => username,
           "accessKey" => accessToken,
           "build" => "Ecommerce Wait Test v.1",
           "name" => "Ecommerce Wait Tests",
           "platformName" => "Windows 11"
         },
         "browserName" => "Firefox",
         "browserVersion" => "100.0",
       }


       @my_driver = Selenium::WebDriver.for(:remote,
                                         :url => "https://"+username+":"+accessToken+"@"+gridUrl,
                                         :desired_capabilities => capabilities)

       @my_driver = Selenium::WebDriver.for :firefox
       @url = "https://ecommerce-playground.lambdatest.io/"

       @my_driver.get(@url)

       # Set an implicit wait time
       @my_driver.manage.timeouts.implicit_wait = 30

       # Set the explicit wait time for a maximum wait of 60 seconds
       @wait = Selenium::WebDriver::Wait.new(:timeout => 60)

     end

     def test_search_functionality_should_yield_results

       assert_equal(@my_driver.title, "Your Store")

       search_box = @my_driver.find_element(:name, "search")

       search_box.clear
       search_box.send_keys("phone")
       search_box.submit
       sleep(5)

       # Call the explicit wait time - Here, the waiting time will be set to 60s and not the 30s.
       search_title = @wait.until { @my_driver.find_element(:xpath, '//*[@id="entry_212456"]/h1') }

       # Second test assertion - title has loaded
       assert_equal("Search - phone", search_title.text)
     end

     def teardown
       @my_driver.quit
     end

    end

Code Walkthrough:

In the explicit wait code, we use the defined, explicit function on our Selenium methods.

We set our explicit function as a variable called @wait — which we call later in our test, as shown below.

Fluent Waits in Selenium Ruby

Fluent waits support an exponential wait time where the wait time is a function of the wait function. The exponential waiting allows for more control over how long to wait for elements — for example, in an eCommerce site, you may wish to test that an element can appear before being clicked before you proceed.

The fluent wait will allow you to check frequently after a specified amount of time before increasing the wait time.

Syntax (Fluent Wait):

    @fluent_wait.until { @my_driver.find_element(:name, "search-box-doesnt-exist")

Demonstration: Fluent Waits in Selenium Ruby

    require 'selenium-webdriver'
    require 'test-unit'

    class EcommerceTests < Test::Unit::TestCase
     def setup
       username= "{LAMBDATEST_USERNAME}"
       accessToken= "{LAMBDATEST_ACCESS_KEY}"
       gridUrl = "hub.lambdatest.com/wd/hub"

       capabilities = {
         'LT:Options' => {
           "user" => username,
           "accessKey" => accessToken,
           "build" => "Ecommerce Wait Test v.1",
           "name" => "Ecommerce Wait Tests",
           "platformName" => "Windows 11"
         },
         "browserName" => "Firefox",
         "browserVersion" => "100.0",
       }


       @my_driver = Selenium::WebDriver.for(:remote,
                                         :url => "https://"+username+":"+accessToken+"@"+gridUrl,
                                         :desired_capabilities => capabilities)

       # @my_driver = Selenium::WebDriver.for :firefox
       @url = "https://ecommerce-playground.lambdatest.io/"

       @my_driver.get(@url)

       # We define the exception we expect
       exception = Selenium::WebDriver::Error::NoSuchElementError

       # Set a fluent wait time for a maximum wait of 45 seconds  - for use later in the tests
       # Here, the error NoSuchElementError is expected to be thrown, but we don't want to fail the test if it does, so we use the rescue block
       @fluent_wait = Selenium::WebDriver::Wait.new(timeout: 45, interval: 5, message: 'Timed out after 45 secs', ignore: exception)

     end

     def test_search_functionality_with_fluent_wait

       assert_equal(@my_driver.title, "Your Store")

       # Here we call an element that does not exist and check that the fluent wait works as expected, we
       # ignore the NoSuchElementError exception and rescue the TimeOutError exception to proceed with the test
       begin
         @fluent_wait.until { @my_driver.find_element(:name, "search-box-doesnt-exist") }
       rescue Selenium::WebDriver::Error::TimeoutError
         puts "Element not found"
       end

     end

     def teardown
       @my_driver.quit
     end

    end

Code Walkthrough:

Let’s have a look at the fluent wait code walkthrough above, what just happened you might ask.

Now that we know what the setup does from examples of implicit and explicit waits in previous sections, we will concentrate more on the test itself.

We define the name of our exception that we intend to ignore in case of the fluent wait times out. This is a NoSuchElementError, which is the exception Selenium throws when an element is not found on the DOM.

You will notice at the setup on line 39 we defined our fluent wait method and then declared our fluent wait method using the interval parameter of 5 seconds. This means that the fluent wait will wait for 5 seconds and then perform a check if the element is available.

Thus before the test fails, the script will have tried to check for the element 9 times since our timeout is 45 seconds. We will confirm this from our test results below.

   # Here we call an element that does not exist and check that the fluent wait works as expected, we
       # ignore the NoSuchElementError exception and rescue the TimeOutError exception to proceed with the test
       begin
         @fluent_wait.until { @my_driver.find_element(:name, "search-box-doesnt-exist") }
       rescue Selenium::WebDriver::Error::TimeoutError
         puts "Element not found"
       end

`We then call an element that does not exist and check that the fluent wait works as expected, we ignore the NoSuchElementError exception and rescue the TimeOutError exception to proceed with the test.

Let’s discuss the usage of the rescue block in our tests.

What are rescue blocks used for while testing in Ruby?

Rescue blocks are similar to try..catch blocks in Java, where you can catch exceptions and choose to do another action in case of an exception. This is useful when you want to prevent a test from failing and do something else instead.

When using rescue blocks in automated testing, we can include multiple types of errors by chaining the rescue blocks together. This is important when we must ignore multiple exceptions while waiting.

Do you know? You can convert Markdown to HTML easily through this tool, just paste your markdown language in the input field & click convert to HTML.

How to run Selenium Ruby tests on a cloud grid?

To run Selenium Ruby tests on a cloud grid, you must set up a cloud-based Selenium Grid, such as LambdaTest. Once you have set up an account and configured your grid, you can use the Selenium WebDriver in your Ruby script to connect to the grid and execute your tests.

Automation testing tools like LambdaTest offer an extensive online device farm comprising over 3000 real devices with real operating systems for performing Selenium Ruby testing at scale. This allows for comprehensive Selenium testing using LambdaTest’s online Selenium Grid.

Do you know? LambdaTest’s free online XML Prettify tool can identify errors in your XML code by highlighting invalid elements, missing attributes, and other issues.

You can also subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorials around Selenium testing, Cypress E2E testing, CI/CD, and more.

Login to access the LambdaTest Dashboard.
Check on the automate tab for your test run.

You should see results similar to the screenshot above, indicating that your tests have run successfully. You can watch the video to see how your test ran. On the right-hand side pane, you have a list showing the execution steps during the test process.

On the cloud, we noticed a NoSuchElement Error thrown, but the tests all passed as we expected — thanks to our rescue method. If we wanted our tests to fail, we would remove the rescue method. These results show what we would expect to see on the LambdaTest dashboard.

*On the section labeled A *— If you check the difference between the time stamps — you will notice it’s 5 seconds. — And this directly correlates to the 5 seconds interval parameter we specified on our fluent wait.
*On the section labeled B *— You will see the NO SUCH ELEMENT defined as the reason the test was unsuccessful. However, you will note that the tests will not be marked as failed because we used a rescue block.

Viewing the dashboard for essential metrics that can help troubleshoot your tests is important. For example, at the top right corner, you can see the browser, operating system, resolution, and the duration taken to run your test — These options can be changed on the capabilities file that we passed earlier to match what you desire to test for.

More information can be obtained by clicking the metadata button, which will give more information about your tests that looks like below.

LambdaTest is a platform that allows you to streamline your test execution process by centralizing all of your test data in one place. This makes it easy for you to access and analyze your test results, so you can make informed decisions about your software development process.

With LambdaTest Test Analytics, you can quickly and easily view test results, compare different test runs, and identify areas where your tests may fail or improve. This can help you to optimize your testing process and improve the overall quality of your software. LambdaTest also provides an easy way to debug and fix issues by providing detailed error logs, screenshots, and video recordings of tests, which can be really useful for developers and testers to troubleshoot issues.

If you are a developer or tester looking to improve your Ruby skills, the Selenium Ruby 101 certification from LambdaTest may be a valuable resource for you.

Do you know? Use this free online CSS prettify formatter to clean up your minified or disorganized CSS code. Your code will be considerably simpler to read and edit if you use this tool.

Conclusion

Waits in Selenium Ruby control which test is executed and when. The implicit wait allows you to specify a wait time for any given test method to run before returning. The explicit wait allows you to perform actions within the specified time before waiting for the element to be found. The fluent wait supports an exponential wait based on certain conditions being true before it executes.

All these wait methods are very important in Selenium. They help you achieve test reliability and reduce the number of tests that might have failed because of a timeout or another error you might want to catch.

How To Maximize Browser In Selenium Ruby

Roselyne Makena — Fri, 02 Dec 2022 15:06:44 +0000

As testers, we’ve probably all encountered bugs that occur when a browser is resized. Although many browsers nowadays have improved the quality of their resizable windows, I am sure every tester should know how to create a resizable window on purpose while performing automation testing.

For example, how can you make the browser window smaller to accommodate certain elements? Conversely, can you maximize the browser? This entire blog delves into how you can minimize and maximize browser in Selenium Ruby.

Selenium is a great automation testing tool, but it works best with Ruby to create a powerful automation solution. Ruby offers clean syntax and enhanced library support, making it an ideal choice for automated browser testing of web applications.

This Selenium Ruby tutorial will teach you how to maximize browser in Selenium Ruby and minimize and resize it to different sizes.

Why do we need to maximize the browser window?

A browser window is a limited storage space used to display web pages. The browser window size and position may change depending upon the size of your monitor display and the operating system you are using. For example, if you are using a large screen monitor, your window size will be larger than that of a small screen like a mobile phone or a tablet.

If you are wondering how to check whether your website is responsive across different screen sizes, you can try this free responsive checker by LambdaTest.

Depending on the operating system, the browser window may not fill up your whole screen. If a browser window is not maximized, the user can only see a portion of the window, reducing your site’s visibility and consequently affecting the testing process.

It’s always good to incorporate Selenium best practices and maximize your browser when running automation tests because it is much easier to test many different elements on your page. It is also the default behavior for most users when viewing your webpage.

There are very many screen sizes available in the market today. The different sizes are determined between the designers of a website and the developer of a browser. While working, many people do not want to see only a small portion of the web page. They need to see what is being displayed at that particular moment.

At any given time, users would use their choice of the device when accessing your website or the web app. This fragmentation in using devices, smartphones, tablets, and laptops creates a need to ensure that your automation tests cover those possible scenarios.

If a certain browser is only tested with just one browser window size, it might not work as expected if users use different browser window sizes. Therefore it is important to test your application using multiple browsers and viewport sizes to ensure that it works as expected on any screen size.

Having said that, if you are testing your application, it is important to see the full web page to ensure that everything is being displayed as expected so that you can test all possible scenarios. To achieve this, you need to maximize your browser window. Maximizing the browser window simply means that it fills up the screen, and you can see more of your site.

Viewing a link or element outside the browser window

What happens when you click on a link that loads a web page outside your browser window?

To view a link or element outside the browser window, you can approach this in different ways. We may need to scroll the page to find that element in scrollable web pages. However, if your window is maximized and the element is in view, you can click on the link and navigate to the new page.

In our test demo code, we will look at the following test scenarios to see the different screen sizes in which a browser can be minimized during web testing.

Load our test page and maximize the browser.
Minimize our browser to the tab.
Resize our browser to a defined size.

What is minimizing the browser?

Minimizing refers to docking the browser to the taskbar so it is not visible on the screen. This is common when using other applications while you want to access the browser at some later stage.

Most browsers have three buttons at the top bar to handle this by default. One button will maximize the browser, the other will minimize it, and another will close the browser — as shown below.

Button used to close the browser.
Button used to minimize the browser.
Button used to maximize the browser.

Note that different operating systems and browsers may present this in a different order or design, but the basic concept remains the same.

Check this out: Smoke Testing Tutorial - A Comprehensive Guide With Examples And Best Practices

What is browser resizing?

Resizing refers to changing the browser window’s size to a specified size. A user resizes a browser window by clicking one of the edges of the browser window and dragging it to a different size. The default buttons for resizing are the two hands of a window, as shown above in the picture.

During resizing while writing our Selenium Ruby demo code, we will provide a height and a width for the browser window. We will then be able to use the height and width to change the size of our browser window by using the WebDriver API.

Run your Selenium Ruby test scripts across 3000+ real browsers and OS. Try LambdaTest Now!

Scenarios where you need to resize or minimize the browser when testing

When designing a website, it’s important to consider what happens when your design is viewed on various platforms, browsers, and screen sizes. While you may be able to design a site that works perfectly fine on your computer with its 1920×1080 resolution and Retina display, other devices and settings may affect how your design looks.

With the wide variety of platforms and browsers available today, it’s essential to test your designs on all of these settings before you launch them to the public, whether you’re launching a new website or just making adjustments to an existing one. To do this type of testing effectively, you need to know how to resize your browser so that it matches the size of other devices and adjust each browser’s default zoom.

Below are some scenarios where you’ll want to resize or minimize the browser:

When you cannot see the element you are trying to test, you can maximize the browser window and scroll down to find that element.
If you want to ensure that the tested element is visible on the page for a maximized/minimized window size, then resize your browser window to the size being tested for.
You can zoom in and out of a web page when you rotate the view of a web page or a map using the mouse. Therefore we need to resize our browser window for this purpose.
Ensure that the page fits into your browser window when simulating a view on a mobile device.
Your web page may have scroll bars, and you need to scroll down at a certain browser size to view what is showing in that view (or window).
When you resize your browser, some websites automatically fit the webpage (to reduce white spaces). Padding sizes change when browsers change sizes and might affect the visibility of content. In addition to padding-top and padding-bottom, there are several other CSS properties for positioning siblings. You can refer to this CSS Cheat Sheet to learn more about those properties.

Note that not all browsers conform to the standard. For example, Opera and Webkit do not implement margin auto, or the four sides of a box have different effects depending on the implementation. Therefore, the precise behavior of margins may be different in a browser’s implementation, thus the need to test this for different browser window sizes.

For example, a maximized vs. a minimized window size clearly shows that different elements are shown by displaying more spaces in the minimized window size.

Minimized browser windows showing white spacing and less content in the viewport.

Maximized browser windows showing less white spacing and more content in the viewport.

How to maximize browser in Selenium Ruby with code examples?

In this section of this blog on how to maximize browser in Selenium Ruby, we will learn about the prerequisites and see the implementation with code examples.

Pre-requisites

Here are some prerequisites before we see how to maximize browser in Selenium Ruby on the cloud.

IDE

We will be using Visual Studio Code, but you could use the IDE of your choice. Other popular Text editors include RubyMine, Sublime, Atom, etc.

Selenium Cloud Grid

Selenium cloud grid is a hosted Selenium Grid solution. This system provides an easy way to run your tests on multiple platforms without running all browsers on your desktop.

It allows you to perform parallel testing distributed over multiple cloud providers. If you have a team of testers running Selenium IDE tests for multiple projects, you can now utilize the cloud to scale up your testing capacity. You can also speed up your development cycle by running the same test against different environments with different browsers. For this blog on how to maximize browser in Selenium Ruby, we will run our test on LambdaTest’s cloud Selenium Grid.

Cloud-based cross browser testing platforms like LambdaTest provide you with an online browser farm of 3000+ browsers and operating systems to perform Selenium Ruby automation testing at scale. Here’s a glimpse of LambdaTest grid for Selenium automation testing.

You can also subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorials around Selenium testing, Cypress E2E testing, CI/CD, and more.

In order to maximize browser in Selenium Ruby on the cloud grid, we would need to define capabilities and replace our driver with a remote webdriver by having a cloud grid remote webdriver configured.

Implementation

We will write our tests, and instead of using the local Selenium WebDriver, we will directly use the Selenium Cloud Grid to maximize browser in Selenium Ruby and view the test result on the dashboard.

require 'selenium-webdriver'
require 'test-unit'

class BrowserWindowTests < Test::Unit::TestCase
 def setup
   username = "#{ENV['LAMBDATEST_USERNAME']}"
   access_token = "#{ENV['LAMBDATEST_ACCESS_KEY']}"
   grid_url = "hub.lambdatest.com/wd/hub"

   capabilities = {
     'LT:Options' => {
       "user" => username,
       "accessKey" => access_token,
       "build" => "Browser Maximizing Test v.1",
       "name" => "Browser Maximizing Tests",
       "platformName" => "Windows 11"
     },
     "browserName" => "Firefox",
     "browserVersion" => "100.0",
   }


   @my_driver = Selenium::WebDriver.for(:remote,
                                        :url => "https://"+username+":"+access_token+"@"+grid_url,
                                        :capabilities => capabilities)


   @url = "https://ecommerce-playground.lambdatest.io/"

   #get url
   @my_driver.get(@url)
   @wait = Selenium::WebDriver::Wait.new(:timeout => 30)
 end

 def test_page_resizing
   # Assert that title is loaded
   @wait.until { @my_driver.title.include? "Your Store" }
   sleep(2)

   # We maximize the window to occupy the full page
   @my_driver.manage.window.maximize

   # Here we minimize the browser window to the taskbar
   @my_driver.manage.window.minimize
   sleep(2)

   # Here we resize the browser window to a width and height of 500(width) by 1000(height)
   @my_driver.manage.window.resize_to(500, 1000)
   sleep(2)

   # We maximize the browser window again to occupy the full page
   @my_driver.manage.window.maximize

   # Here we resize the browser window to a width and height that's bigger than a normal screen size
   @my_driver.manage.window.resize_to(6000, 6000)
   sleep(2)


 end

 def teardown
   @my_driver.quit
 end

end

Remember to replace your LAMBDATEST_USERNAME and LAMBDATEST_ACCESS_KEY with the ones you obtained after signing up on LambdaTest. You can get these details from the LambdaTest Profile Section.

Export your variables to your environment:

For Linux/macOS:

export LAMDATEST_USERNAME="YOUR_USERNAME"
export LAMDATEST_ACCESS_KEY="YOUR ACCESS KEY"

For Windows:

set LT_USERNAME="YOUR_USERNAME"
set LT_ACCESS_KEY="YOUR ACCESS KEY"

Check this out: System Testing Tutorial- A Comprehensive Guide With Examples and Best Practices

Code Walkthrough

The manage() method gives us an instance of browser menu methods from the Selenium WebDriver that we will use to control our browser window.

After the browser loads, we use the Selenium maximize method to maximize the browser window, as shown below.

To minimize the browser, we call the minimize method, and on running the test, the browser will be minimized and hidden from view.

When we want to resize the browser window, we will call the resize_to method with the width and height of our browser. The height and width values that we specify in the arguments are then used by the **resize_to **method to change our browser window to a different size when resizing is required. The first argument is the width, and the second is the height of the browser window.

Calling maximizes on the browser instance will resize it to its full size that occupies the entire width and height.

What happens if we resize a browser to a larger height and width than our actual screen size?

To demonstrate this, let us resize the height to 6000px and the width to 6000px. Run the test, and you will notice that the browser window will adjust the height and width to the maximum size without showing any warning.

Determining the current size of your browser window

To determine the current height and width of your browser window in Selenium Ruby, you could use the following method.

puts @my_driver.manage.window.size

This would give you results similar to the below, which shows the width and height at the time that method ran. This can be useful in cases where you want to ensure that you are resizing your browser window to a certain size before running a full-screen test.

For some browsers — In cases where you try to resize your browser window while running a test and it doesn’t work, ensure that you are using appropriate values in the resize_to method.

Checking our tests on LambdaTest

Login to LambdaTest to access the LambdaTest Dashboard.
Check on the Automate tab for your test run.

You should see results similar to the screenshot below, indicating that your tests have run successfully. You have the option to watch the video to see how your test ran. In addition, you have a list showing the execution steps during the test process on the right-hand side pane.

Checking Analytics on LambdaTest

To view the test overview and get a summary of all the tests recorded on LambdaTest, click Automation > Analytics on the left side menu. The LambdaTest Analytics Dashboard will provide a summary of all builds and test runs that you have submitted.

You will see results similar to the below.

For any developer or tester looking to start, or advance their career in the technology industry, then you need to look no further. This Selenium Ruby 101 certification will set you apart from the rest of your peers and get you an edge at any job.

Here’s a short glimpse of the Selenium Ruby 101 certification from LambdaTest:

Check this out: Blackbox Testing Tutorial - A Comprehensive Guide With Examples and Best Practices

Conclusion

Having the convenience to modify a browser size to the size that suits your testing needs is crucial to accurately test your application for the real world since it allows you to test your application in its entirety.

Most of the time, using a browser with a width and height of 500px or less will allow you to see what is being shown on the page on smaller screens. This can help you understand how our web application will look at scale — especially on mobile devices.

You can resize, minimize, or even maximize browser in Selenium Ruby using different methods while testing. This ensures that your application will function properly or even give you insights into what the application will look like on various browser sizes.

How To Implement Data Tables In Cucumber Using Selenium Ruby

Roselyne Makena — Thu, 01 Dec 2022 14:24:42 +0000

Data tables can be used when you have data in a range of cells and want to iterate over the cells in order. Data tables generally have a header row that includes column headers and then rows of data.

There are many reasons to use a data table when testing.

Data tables make it easier to see how the calculation is structured for each cell.
Data tables significantly reduce repetition by storing the data that will be used repeatedly in only one place.

This Cucumber Selenium tutorial is about implementing data tables in Cucumber using Ruby as the scripting language. The Ruby language encourages the use of Behavior Driven Development (BDD), a form of Test Driven Development (TDD) that encourages collaboration between developers and non-developers, such as product owners.

Using Selenium Ruby, you can write tests before the code is tested, and then you write the code from the point at which the tests fail. Using a simple example, I’ll show you how to create data tables in Cucumber while performing Ruby automation testing and run the tests to ensure that our tests pass as expected.

So, let’s get started!

Advantages of Behavior Driven Development

Before we deep dive into the essentials of Cucumber, let us recap the major advantages of Behavior Driven Development. The learnings from it will set the context for data tables in Cucumber Ruby — this blog’s primary focal point.

Major advantages of BDD are:

Behaviour Driven Development (BDD) makes it easy to write acceptance tests. These tests will be more readable and look more like a natural language document, making them easier to share with business stakeholders.
The BDD approach forces you to consider how your application might be used before you start writing any code. This gives you a better understanding of your domain and leads to better-designed software.
It reduces the need for lots of integration testing because many of the requirements have already been tested during the development process by writing automated acceptance tests using Cucumber.
Writing your scenarios using a standard format means you can run them across different development tools, and they’ll all work the same way.
Agile teams can benefit from Cucumber because running your scenarios will give you early feedback on whether you’re building the right software or need to change track and deliver something different. This can be invaluable in an iterative development process where small changes are made frequently.
Maintaining and expanding your system is easier because other team members can understand how it works by reading acceptance tests written at the start of the project.
Failure to write your Cucumber tests correctly is a common problem, but it’s easy to spot because they look like natural language. You’ll always know what needs to be changed or added to improve the quality of your tests.

What is Cucumber?

Cucumber is used in many languages, including Java, Python, and Ruby. It is very popular with frameworks because it is easy to test methods with assertions covering most use cases.

It is a popular tool for running automated acceptance tests. In short, you create a plain text file (Feature file) that contains descriptions of the scenarios (i.e., different ways a user might interact with your application). You could run Cucumber using Ruby to execute the scenarios and generate a concise report of whether each scenario passes or fails.

Cucumber embraces Behavior Driven Development, which means you write your scenarios in a natural language, speaking to the application as a user would. Cucumber utilizes Gherkin — a lightweight programming language that looks like English.

Gherkin is a Domain Specific Language (DSL), meaning that you have different keywords for different steps in your scenarios compared to standard programming languages such as Ruby, Python, and Java.

Cucumber support for other frameworks and tools

Most Cucumber users use it with Ruby, but it can also be used to test applications written in other languages. For example, you could write your scenarios using JavaScript as a scripting language, and your steps could interact with a web browser rather than a web application.

Cucumber provides support for Capybara in the form of a Capybara driver. Once installed in your test suite, Capybara will launch a browser window before each scenario and navigate to the specified URL and the text in the title bar.

Cucumber also supports Ruby on Rails (ROR), Watir, and Spring framework, among others.

Cucumber syntax

Features — A feature in the software world is generally a small section of functionality you would like to test. In Cucumber terminology, a feature is an expectation that must be true to pass any scenario. For instance, imagine you want to test if a user can log in with a username and password combination. I will refer to this as the scenario “User can log in”.
Scenarios — A scenario is how the features are connected. A scenario generally describes what the user should do next, or in other words, what behavior your application should have during that particular flow step. This way, users can see if they have done everything they need and if they still need to proceed forward.
Description — The description is a narrative description of the behavior that the user should have. It should be written in a natural language and not repeat any information contained in the feature or step definitions. Let’s say a scenario is “User can login”. The description for this scenario will be “The user should see a screen where he can enter his username, and then see another screen where he can enter his password.”
Given — This is a statement that states what the system should be like at the time of running this scenario (pre-requisites). This allows us to describe the state of reality we need to have for our application to work as expected and pass any subsequent test scenarios. In other words, if no errors are occurring, then we should be able to proceed to the next steps indicating that everything is working as expected.
When — this is an “if” statement stating what you want the application to do when you run your scenario. Let’s say if a scenario is “User can log in”, then we would write, “When one or more users try to log in they should see a page outlining what they need to do next.
And — the “and” is the “and then” statement which connects the steps together. It’s like an “if-then” statement, but with two conditions instead of just one. In Cucumber, you write one at the end of every step as it marks the beginning of a new scenario.
Then — this part is where we check whether our application did what we expected it to do when running our scenario. The Cucumber framework will automatically check that all your “then” steps are true before continuing to the next step in your scenario
Steps definitions — these are the steps where you specify what should happen in each scenario. They are written in Ruby, and you must specify what the application should do when you run a specific step.
Cucumber hooks — hooks are a particular type of Cucumber annotation that allows you to use specific code in your steps that you may have written elsewhere. This helps to avoid repetition and errors in your code.

Some examples of Cucumber hooks are :

Before hook: runs before every scenario.
After hook: runs after every scenario.
Setup hook: runs before any scenario.
Teardown hook: runs after any scenario.
Step definition hook: runs when the step is about to be executed or has just been executed.

It’s important to note that we can have tagged hooks — Which are used for step definition hooks.

The Cucumber Ruby gem comes with a few additional pieces of functionality that are not related to the Cucumber framework itself. Pieces of functionality such as report generation, database-driven steps, and database-driven reporting are all built into the cucumber gem.

While I’m not going to be covering any of these as it is outside of the scope of this blog on data tables in Cucumber, it is something that you may want to look into if your system has a lot of complicated interactions and requirements for every scenario you have defined.

How to run Cucumber?

Here are some ways to run Cucumber:

The first is using a DSL (Domain Specific Language). A DSL is a programming language that you write yourself to create the equivalent of English descriptions.
The second way is using the built-in Rails features, which might be easier for certain programmers to implement if they’re unfamiliar with writing DSLs.
Thirdly, we can also use actual Ruby code (which is probably more common) — and this is how we will use it to run our tests.

Having gone through the basic functionality of Cucumber syntax, let’s look at data tables in Cucumber.

For developers or testers looking to elevate their skills, you need to look no further. This Selenium Ruby 101 certification can get you in the door at any organization and ready to climb your way to the top.

Here’s a short glimpse of the Selenium Ruby 101 certification from LambdaTest:

Check this out: How To Debug Websites Using dev tools in Safari

What are data tables in Cucumber?

A data table (or data matrix) is a special type of table that allows us to compare a set of numerical values simultaneously easily. It’s great for displaying data that you would like people to understand at a glance.

Data tables are most useful when working with data that is numerical. Data tables can be found in almost every business, from insurance to airlines.

They are used for displaying numbers and statistics. Still, they can also be used as a simple way of providing information about a range of choices and doing multiple tests for a particular scenario, as we will use today.

Implementing data tables in Cucumber

To implement a data table in Cucumber, you need to create one or more files named after your feature. Let’s look at the breakdown below to understand this.

To create a data table, you first need to create a file named after your feature containing your scenario. Then you add some text starting with “Given” to describe the data that the system should have before your schemas (in this case, a table) is displayed.

Let’s look at a coding example to help us understand data tables in Cucumber better.

Check this out: Emulator vs Simulator vs Real Device Testing - Key Differences

How to implement data tables in Cucumber using Ruby?

We will be testing that different users can log in successfully to our test website and use data tables in Cucumber to make it easy to track our results. The data table structure will help us write the test case once and then re-use it with sample data.

Prerequisites for implementing data tables in Cucumber

Ruby

Make sure you have Ruby installed on your system. To confirm the version of Ruby you are running, type the below command in your terminal.

ruby -v

To learn more about installing Ruby, you can go through my earlier blog on Selenium automation testing with Ruby. You should see results below, based on the version of Ruby you have on your system.

Cucumber and Watir gem

To run Cucumber tests, we must install the gem cucumber, and we do this by running the below commands on your terminal:

gem install cucumber
gem install watir

You would expect a successful installation, which you can confirm by using the list command below.

Note: For watir — you need watir, and you do not need to have watir-webdriver listed.

When writing this blog, the latest version of Cucumber was 8.0.0. This version might vary based on the latest version of Cucumber available then.

Implementing Cucumber data tables

Let’s start by creating the Cucumber folders necessary for this project. Navigate to the folder where you will run your tests and run the following in your terminal.

cucumber — init

We expect to see a couple of folders created that are similar to the ones below.

2- To successfully run our tests, we will create four files. We shall go through each one in detail afterward.

3- First, let’s create a features_files directory. To do this, type the following into your terminal.

mkdir features_files

4- Inside the features_files folder, create a file called the login_tests.feature. We can then type in the code below.

#/features_files/login_tests.rb
Feature: Ecommerce login Feature
 Scenario: Verify ecommerce webpage loads and user can sign in
   Given Ecommerce webpage Login Page loads
   And Ecommerce Login Link is present loaded
   Then Correct Username and Password Should Login Successfully <username> <password>
   And My Account page should display after login
 Examples:
   | username                       | password      |
   | kankanaadds@gmail.com          | LambdaTest123 |
   | swapnilbiswas012@gmail.com     | LambdaTest123 |
   | himanshi.jainn@rediffmail.com  | LambdaTest123 |
   | saumya.saran01@gmail.com       | LambdaTest123 |

Then create another directory inside features called page_object, create a file called login_page.rb. This will be where we shall write our page object functions and use them in our tests. To learn more about Page Object Model, go through our earlier blog on Page Object Model in Selenium.

#/page_object/login_page.rb
class LoginPage
 def username_link
   $browser.link(text: "Forgotten Password")
 end

 def username_textbox
   $browser.input(id: "input-email")
 end

 def password_textbox
   $browser.input(id: "input-password")
 end

 def login_button
   $browser.button(value: "Login")
 end

 def account_header
   $browser.link(text: "Edit Account")
 end
end

Run your Cucumber test scripts across 3000+ real browsers and OS. Try LambdaTest Now!

What are Page Objects in Cucumber?

Page objects are a way of creating test objects specific to your application. In Cucumber, they are used to create and manage page objects so that we can interact with third-party code and databases.

They come in handy when the object you’re writing must not be directly dependent on Rails’ usual classes, models, or collection structures.

Think of page objects as ‘functions’ for creating object instances — except they don’t just create objects based on classes or named collections — they instead create instances based on whatever values you input them in the text you supply them with.

When do you use page objects?

The page object is the simplest way to separate locators from the rest of the application. A new class can easily be added to a page object that concentrates all locators used on that page. Therefore, it is best to separate these locators so they do not interfere with testing. To learn more about locators, go through our earlier article on locators in Selenium.

In the next section of this article on implementing data tables in Cucumber, we will look at some of the benefits of using page objects.

Check this out: Online Safari Browser Testing For Windows - Say No To Safari VM! Perform Cross Browser Compatibility Testing On All Safari Browser Versions Across Real Browsers And Operating Systems.

What are the benefits of using page objects?

Using page objects helps us separate locators from functional code by defining them as properties on a ‘page object’ class definition.

Ability to define locators on multiple user interface pages without duplicating locator definitions or coding.
Immediate integration with existing test automation frameworks with minimum code changes required by the automation team.
Elimination of the need for test automation frameworks to support session-level locators when viewing multiple pages.
The ability to specify a relative path for each page object.

When creating a page object, it is generally required to define properties that describe the page containing the page object.

It’s important to note that we do not have to link each locator’s definition of a test automation framework with each page object. During testing, the recommended approach for an automation team is to reference a single class definition file rather than hundreds of locator definitions in each test script or have separate locator definitions grouped in a specific order and valid naming conventions. This makes it easier to find a page object.

For the third file, we shall create a file under step_definitions(a folder that already exists) and create a file called ecommerce_steps.rb.

Here, we will have all our step definitions for our Cucumber test. For example, we will have a function for navigating to the login page that we will use in the login scenario.

When creating a page object, it is generally required to define properties that describe the page containing the page object.

For the third file, we shall create a file under step_definitions(a folder that already exists) and create a file called ecommerce_steps.rb.

Here, we will have all our step definitions for our Cucumber test. For example, we will have a function for navigating to the login page that we will use in the login scenario.

#/step_definistions/ecommerce_steps.rb
Given(/^Ecommerce webpage Login Page loads$/) do
 $browser.goto "https://ecommerce-playground.lambdatest.io/index.php?route=account/login"
 $user_session = LoginPage.new
end

Then(/^Ecommerce Login Link is present loaded$/) do
 assert($user_session.username_textbox.name, "email")
 assert($user_session.password_textbox.name, "password")
end

Then(/^Correct Username and Password Should Login Successfully (.*) (.*)$/) do |username, password|
 puts "------"
 puts username
 $user_session.username_textbox.send_keys(username)
 sleep(3)
 $user_session.password_textbox.send_keys(password)
 sleep(3)
 $user_session.login_button.click
end

And(/^My Account page should display after login$/) do
 assert($user_session.account_header.name, "My Account")
end

Lastly, we will edit our env.rb file, which is under the support to have the following details.

#/support/env.rb
require 'rubygems'
require 'watir'

Before do |scenario|
 $browser = Watir::Browser.new :firefox
 $browser.driver.manage.window.maximize
end

After do |scenario|
 $browser.close
end

Check this out: Most Comprehensive Selenium IDE Tutorial

What is Watir?

Watir is an abbreviation that stands for Web Application Testing In Ruby. It is a much-improved descendant of WebInspector. It’s written in Ruby and provides the same functionality for testing web applications. It has a test runner called Watir-webdriver and a page object for the browser interface.

Watir is packaged in a Ruby gem. It comprises a set of Ruby scripts that relate to the Browser Object Model (BOM). The BOM is the JavaScript API used by the web browser to interact with a web application.

After copying the files we discussed above, you should have an output similar to the one below — and you can confirm by using the ls command to list the content of a given directory (in this case, the tables directory). From our IDE, we should see the following.

Code Walkthrough:

Let’s take a deeper look at the different files.

Filename: features_files/login_tests.rb

This file defines a Scenario and has a name in the format of Given, When, and Then. Given is where we define our scenario, when is where we specify the step definitions for the scenario, and then is where we can write the assertions for that step.

Every feature has at least one scenario. A scenario describes a specific event that should happen to fulfil one or more business requirements in your application.

A scenario follows a pattern of steps and context described in user interaction with the system, e.g., verifying a user can log in to a particular web page.

Note that the example at the end gives access to a data table that provides different usernames and passwords for the test. Data tables in Cucumber are kept around so that the same scenario can be repeated with different data.

Filename: page_object/login_page.rb

The page object is responsible for creating the objects that your scenario needs to interact with. The object that the page object creates is instantiated when you run the scenario. This is an instance of a page object, which provides a given page. In this case, it’s our login page.

The page object is usually defined for you as part of Cucumber, but there are some cases where you need to customize the object or create your own. You can define just about any CRUD, static or dynamic web page in Ruby as your real-world implementation by working with the methods in your Page object.

For example, if we want to specify the user’s name when we log in and then check that data, we can add those variables to our env.rb file and pass them into our step definitions as needed.

Filename: step_definistions/ecommerce_steps.rb

These are the step definitions that show the real meat of your scenario! This is where we define our step definitions, which are executed one after the other and at the end. We have an assertion that verifies whether the expected outcome happened or not.

We can then add variables to our step definition file in Ruby and pass those variables from our data table to our scenario. This is how we can check for particular values when a page loads or clicks a button.

Filename: support/env.rb

As we mentioned earlier, the env.rb file usually contains general information that can be reused across the different steps of your test or used across multiple features in the same project. In our case, we have included Cucumber hooks such as Before and After.

The Before method here will run once before each scenario and will simply create a browser session and maximize the browser.

The After method will quit the browser after each scenario has run.

Execution:

To run the test, we need to open our terminal at the root of the folder where we created the Cucumber file and run the following command.

cucumber

This just runs all the feature files, but if you need to specify which one you want to test, you can run the following from your terminal.

cucumber features/features_files/login_tests.feature

That’s it! We have successfully written and run a feature using cucumber. Let’s take a closer look at some of the files we created in our Cucumber project.

What happens if the test fails?

You must open your terminal and change some values in your login_tests.feature file if an error occurs. You could do this by changing the username or password.

We will see error messages on the console log when running the tests.

The error messages displayed are very helpful for debugging or understanding what the test is getting wrong. As you can see, they display a specific line number that failed and then gives you a message about what exactly failed.

The great thing with data tables in Cucumber is that other tests continue to run even if there is a failing test. This means that it will not give you false results when there is an error, and you can always debug the problem by changing some values in an invalid way and see the test result.

You’ll notice that when there are multiple tests, Cucumber will display all of them and give a summary of failed or passed tests along with the steps taken.

By now, you should better understand how Cucumber works and how it helps you write your tests for your application’s business logic code.

Now let’s run our feature files and ensure everything works as expected.

In the folders created, it’s important to note that the env.rb file under the support folder runs first when the test begins, and then the files in the step_definitions follow.

env.rb contains configurations for your system, e.g., database connections, etc. This is where we define all our data tables in Cucumber, and we’ll create one for every feature. In more complex testing where you would need to add database connection parameters, you would add them in this file.

Every time you run Cucumber, it will check if the env.rb file is present; if not, it will generate one for you with all the necessary values required to execute your test.

After running the tests, we should get the following information in our terminal. As you can see, all the four scenarios from the data tables in Cucumber ran subsequently.

You should expect to see something similar to the below.

When we run the tests, it does a pre-pass first, executes the test, and finally prints out the results.

How to implement data tables in Cucumber on cloud grid?

Selenium Grid is a tool for distributing the load across multiple browsers. Selenium Grid can be used to run tests on different operating systems and browser configurations simultaneously. The grid configuration will control which browsers run the tests and how many of them at a time.

To run this on the cloud grid like LambdaTest, you would need to replace the local webdriver with the remote webdriver. Cloud-based cross browser testing platforms like LambdaTest provide you with an online browser farm of 3000+ browsers and operating systems to perform Selenium Ruby testing at scale. Here’s a glimpse of LambdaTest online Selenium Grid:

Check this out: Automated Functional Testing- What it is & How it Helps?

You can also subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorials around Selenium testing, Cypress E2E testing, CI/CD, and more.

Replace the following code on the file

/support/env.rb

On local Selenium Grid:

#/support/env.rb
require 'rubygems'
require 'watir'

Before do |scenario|
 browser = Watir::Browser.new :firefox
 $browser = browser
 $browser.driver.manage.window.maximize
end
After do |scenario|
 $browser.close 
end

On cloud Selenium Grid:

#/support/env.rb
require 'rubygems'
require 'watir'

Before do |scenario|
 username= "#{LAMBDATEST_USERNAME}"
 accessToken= "#{LAMBDATEST_ACCESS_KEY}"
 gridUrl = "hub.lambdatest.com/wd/hub"

 capabilities = Selenium::WebDriver::Remote::Capabilities.new

 capabilities['platform'] = 'Windows 11'
 capabilities['name'] = 'Cucumber Login Tests'
 capabilities['build'] = 'Cucumber Test v.1'
 capabilities['browserName'] = 'Firefox'
 capabilities['browserVersion'] = '100.0'

 $browser = Watir::Browser.new(
   :remote,
   :url => "https://"+username+":"+accessToken+"@"+gridUrl, :desired_capabilities=>capabilities)

 $browser.driver.manage.window.maximize
end

After do |scenario|
 $browser.close

Remember to export your Username and Access Key in environment variables via your terminal with the commands below.

For Linux/macOS:

export LAMDATEST_USERNAME="YOUR_USERNAME"
export LAMDATEST_ACCESS_KEY="YOUR ACCESS KEY"

For Windows:

set LT_USERNAME="YOUR_USERNAME"
set LT_ACCESS_KEY="YOUR ACCESS KEY"

Checking results on LambdaTest:

You should see the tests fire up on the Automation Dashboard and the results displayed on the right as shown.

You will notice that the number of rows on the data tables is equivalent to the number of tests that are run, which is precisely what we expect, and this also highlights why data tables in Cucumber are essential.

You can view your test results and overall performance on the LambdaTest Analytics Dashboard. From the Test Summary section, you can easily see which tests failed and which passed, as well as how many. You can also navigate to the Test Overview page, where you can see a breakdown of all test runs, including individual test performance.

Cut down test execution by more than 10X. Try LambdaTest Now!

More debugging tips while implementing data tables in Cucumber

If you are getting errors on Cucumber and want to know where the error exactly is happening, then we need to take one step back. Even though Cucumber tries to create a test for all your features, it doesn’t always do so due to duplicate scenarios or missing data tables in Cucumber.

To fix this, you need to navigate the tests and change the test itself. If you still have issues, you can dive deeper into your code using a debugger.

A debugger is a tool that allows you to step into your code, change things like variables and rerun the same scenario. The debugger enables you to see what’s happening as you run your tests step by step.

Once we have what is causing the error, we can look at the failing scenarios and fix them. Remember that some features might not work in a certain environment or browser. So what works for me might not work for you. So don’t be afraid to change these scenarios and add more complex ones.

We can use a gem called Ruby-debugger that gives us the lines in our code that are failing by following these steps.

Try LT Debug Chrome Extension for debugging websites!

Check this out as well: Usability Testing - A Comprehensive Guide With Examples And Best Practices

Conclusion

Ruby and Cucumber provide a powerful toolset for creating automated tests, which can be used to drive the development of complex applications. It lets you focus on the code that matters and let Cucumber do the heavy lifting of automation.

Cucumber is structured for reusability. This means we can easily use the same step definitions in future scenarios by following Cucumber’s best practices. They can be used to enable the system to run tests multiple times without changing any of the logic implemented in the steps and thus is a good tool of choice when it comes to repetitive testing.

More advanced automation testing scenarios such as automated browser testing are possible with Cucumber and Watir but would require more complex step definitions and a significant amount of setup time.

This goes a long way in keeping your codebase bug-free while allowing you to write more complex tests requiring lots of manual interaction. It’s not uncommon for developers to write lots of tests, often manually, but it still costs them time and effort when they’re not particularly complicated.

Getting Started With Automation Testing Using Selenium Ruby

Roselyne Makena — Wed, 30 Nov 2022 15:36:22 +0000

Ruby is a programming language which is well suitable for web automation. Ruby makes an excellent choice because of its clean syntax, focus on built-in library integrations, and an active community. Another benefit of Ruby is that it also allows other programming languages like Java, Python, etc. to be used in order to automate applications written in any other frameworks. Therefore you can use Selenium Ruby to automate any sort of application in your system and test the results in any type of testing environment

In this Selenium Ruby tutorial, we’ll take a look at how we can use Selenium Ruby for automated testing with some sample code that demonstrates this technique. By the end of this post, you should have a good understanding of how Selenium Ruby works and what it does. In addition, you will also learn where to get started writing your own tests with Selenium-based frameworks and how to run the tests on a cloud Selenium Grid.

What is Selenium?

Selenium is a browser-based test framework that allows one to automate user actions and interactions with web applications. You can use Selenium WebDriver APIs to devise test code using Selenium-supported languages like Ruby, Java, JavaScript, C#, and Python.

Selenium and Ruby can be used together, and one of the best ways to do it is through using a gem called selenium-webdriver. With this gem, you can easily automate your test cases using other Ruby-supported frameworks — which we shall introduce below. We will be using Ruby on Selenium in our example, but you can also use your preferred language for automation with Selenium.

Selenium is a powerful tool as it has support for most major web browsers and supports almost all OS platforms- Windows, Linux, and Mac. Selenium can be used to build both automated and manual test cases.

So, let’s get started with automation testing with Selenium Ruby.

How does Selenium WebDriver in Ruby work?

Selenium WebDriver is a Gem that wraps the WebDriver server and makes it easier to drive a browser. WebDriver is a program that can control a web browser.

Selenium WebDriver is used to drive the browser and perform actions on web pages. This tool is bundled with the selenium-webdriver project, and it consists of a Ruby Gem to ensure it can be easily consumed by Ruby. It also consists of code that drives any kind of browser supported by Selenium, such as Firefox, Chrome, Safari, Opera, and Internet Explorer.

If you want to learn more about selenium Selenium WebDriver, you could read this Selenium WebDriver tutorial.

There are several other Ruby Gems for Ruby automation testing, such as Capybara, which runs on top of Selenium; however we’ll be discussing Selenium in this blog.

Check this out: Playwright Automation Tutorial- Getting Started With Playwright Framework

Installing Selenium WebDriver

You could install Selenium WebDriver in two common ways:

Using the Gemfile

Since it is available as a Gem, you could also install it using a Gemfile by including it as shown below:

gem 'selenium-webdriver', '>= 3.142.7'

And then run the bundle install on your terminal.

Installing via Gem

You can also install it by running it as a command on the terminal. Simply run:

gem install selenium-webdriver

How to use Selenium with Ruby?

In Ruby, you can create an instance of the WebDriver class by either instantiating an object or by starting a session. The instantiated object returns a session object of the WebDriver.

To instantiate a driver with the session object, we would need to do the following

@my_driver = Selenium::WebDriver.for :firefox

@my_driver has an instance of Firefox at this point. With the session object, we can now execute certain commands. Let’s try some:

Basic Selenium Ruby methods

Selecting elements

@my_driver.find_element(:name, “elementName”) — Selects an element by its name.
@my_driver.find_element(:id, “textBox1”) — Selected element has an ID of textBox1.

2- Checkboxes

@my_driver.get(1).is_checked? — Returns true if the checkbox is checked. Otherwise false.

3- Radio buttons

@my_driver.find_element(:name, “radio2”).click — Selects a radio button and then clicks it in order to select it.

4- Dropdowns

*@my_driver.find_element(:name, “dropdown1”).click *— Selects a dropdown and then clicks it in order to select it.

5- Submit buttons

@my_driver.find_element(:name, “submit”).click — Selects a submit button and then clicks it in order to select it.

6- Form Elements

text_box = @my_driver.find_element(:name, “textBox1”) — Selects element “textBox1” by its name.
*text_box.send_keys(“hello”) *— Type in the word “hello”.

7- Windows

@my_driver.execute_script(‘window.open()’) — This will open a new window.
@my_driver.quit_now — Closes the current browser window immediately.

8- Timeouts

@my_driver.implicitly_wait(0) — This is to wait for the element without specifying the time in seconds.
@my_driver.implicitly_wait(30) — This is to wait for 30 seconds to load an element, e.g., window/frame, etc.
@my_driver.implicitly_wait(10, TimeUnit::SECONDS) — This is to wait for elements within 10 seconds, and TimeUnit::SECONDS is a class that comes with Ruby.

These are just a few. There are many more methods and arguments that you can use to develop your automated tests using Selenium Ruby. I would cover those in the further blogs of this Selenium Ruby tutorial series.

You can easily program Selenium Ruby tests using any Selenium compatible library. We will implement a simple Selenium automation test in Ruby using the Test::Unit framework.

For developers or testers looking to elevate their Ruby skills to the next level, this Selenium Ruby 101 certification from LambdaTest can be just what you need.

Here’s a short glimpse of the Selenium Ruby 101 certification from LambdaTest:

Check this out: Playwright automated testing Tutorial- Getting Started With Playwright Framework

How to run the Selenium test using Test::Unit?

In this section of this article on Selenium Ruby, we will learn how to run the Selenium test using one of the most popular Ruby frameworks, Test::Unit. Let’s understand more about the Test::Unit framework before getting started.

What is Test::Unit?

Test::Unit is a basic unit testing framework for Ruby. Test::Unit was initially designed to test the Ruby Standard Library and has since expanded to cover almost all of the standard Ruby classes and modules.

Test::Unit uses subclassing for tests so that you can use inheritance for your test classes. The most basic skeleton for a Test class is shown below:

A Selenium script is a Ruby class that inherits the code from the Ruby library ‘Builder’ and contains methods that implement your test plans.

Pre-requisites

Ruby

I’m using Ruby 3.0.3 and Selenium WebDriver 4.1.0. If you have an older version of Ruby or Selenium WebDriver, you can check the Ruby version by opening the terminal and typing the following.

ruby -v

You should expect to see results similar to or close to the following.

**Note: **If you do not have Ruby installed, you can download Ruby from the Ruby official documentation. You could use an older version of Selenium and Ruby — however, there might be some minor changes to watch out for.

2- Selenium WebDriver

First, check whether you have Selenium WebDriver installed by typing the following in your terminal:

gem list selenium-webdriver

In my case, you can see I have Selenium WebDriver (4.1.0) locally installed already.

3- Browser

We will be using Firefox for this example. Other browsers supported and available for tests include Chrome, Microsoft Edge, and Opera.

4- IDE

We will be using Visual Studio Code, but you could use the IDE of your choice. Other popular Text editors include RubyMine, Sublime, Atom, etc

Run Selenium Ruby tests on 3000+ browsers. Try LambdaTest Now!

Demonstration: Automation Testing with Selenium Ruby

Let’s say you have an eCommerce website where we have a set of tests for demonstration purposes.

Problem Scenario

We start by defining the test cases that we want to cover. A test case is basically a definition of a set of expected behavior, along with the expected output that we expect to test against.

Test Cases

TEST DESCRIPTION	TEST STEPS	EXPECTED RESULTS
Test that you can reach the homepage.	Visit the base page and assert that the homepage has been loaded.	The homepage should load the page.
Test that you can filter for an item on the filter box.	Visit the base page, search for an item in the search box and assert that the search filter page has been loaded.	The expected search filter page should load.

Implementation

require 'selenium-webdriver'
require 'test-unit'


class  EcommerceTests < Test::Unit::TestCase
 def setup
   @my_driver = Selenium::WebDriver.for :firefox
   @url = "https://ecommerce-playground.lambdatest.io/"

   #get url
   @my_driver.get(@url)
   @my_driver.manage.timeouts.implicit_wait = 30

   @wait = wait = Selenium::WebDriver::Wait.new(:timeout => 7)

 end

 def test_search_functionality_should_yield_results

   @wait.until{@my_driver.title.include? "Your Store"}

   search_box = @my_driver.find_element(:name, "search")
   # First test assertion - title has loaded
   assert_equal("Your Store", @my_driver.title.to_s)

   search_box.clear
   search_box.send_keys("phone")
   search_box.submit
   sleep(5)
   search_title = @my_driver.find_element(:xpath, '//*[@id="entry_212456"]/h1').text

   # Second test assertion - title has loaded
   assert_equal("Search - phone", search_title)
 end

 def teardown
   @my_driver.quit
 end

end

Code Walkthrough

At the top of our class, we define the test case name. We then define a variable used to override a method of WebDriver (The driver). This is where we create an instance of WebDriver and pass it to the Selenium class, which we inherit from Test::Unit::TestCase.

Next, you need to set up the Selenium server. This step is similar to other testing frameworks and involves installing a Selenium server. It can be done by including the Selenium Gem.

In the EcommerceTests class we start by defining a new blank test case that inherits from the Test::Unit::TestCase class.

Then we initialize our variables in which we define what URL to visit and what to expect.

This is where we create an instance of Selenium::WebDriver and pass it to our class using the name @my_driver.

We then use the get method of Selenium::WebDriver to call the baseUrl method that returns a URL, which in this case is https://ecommerce-playground.lambdatest.com.

After the page has loaded fully, we search for the search box element by its name and make our first test using an assertion.

This also applies to the second assertion, where we add the assert_equal for the filtered item element.

Ending the browser session

The teardown method is a method that Selenium WebDriver implements to terminate the browser session or run methods that need to be completed at the end of the test run. This is important because the number of browser sessions is limited by the driver implementation.

A teardown method will be discarded if invoked before the teardown method for all old sessions has been executed. If two or more teardown methods are invoked simultaneously, only one will be executed, and the others will be discarded.

In this method, we invoke @my_driver.quit in order to terminate the browser session.

Here we are terminating three browser sessions. This can be shown in line 57: of closed browser sessions.

Execution

After running the script, we should observe the following:

As you can see we have our two assertions passing, with 0 errors and 0 failures.

What are Assertions in Selenium Ruby?

A test assertion is a point of critical code that we can test. Usually, assertions are used to verify some conditions, but they can also be used to verify certain values.

assert_true is used to test that a condition is true, and an assert_match is used to verify a value.
assert_match is used to verify a value. For example, we can assign an integer value to a variable, increment it by one, and then use the assert_match assertion to verify whether its value is equal to that of the initial state.
assert_not_find is used to verify that a find operation did not find anything. It is especially useful to test that the find operation works correctly, but we cannot test for it, as it might fail for certain values.
assert_exception method is used to authenticate a failure in a test case. If a failure occurs, the Exception object will be thrown with the message given in the assertion. When checking this method, we should also make sure that all expected exception classes are present.
assert_not_send is used to query that a function call did not launch. In this assertion, we check that the function invoked is not sent as a parameter. Once the find operation is performed and does not find anything, an exception will be thrown. To check if expected exceptions are present, we can use the expect_exception method.
assert_no_error specifies that a specified number of errors should be presented or none should be generated in your test case. Once an error is displayed in your Selenium WebDriver test case, that exception will be ignored by the assert no error conditions when it occurs again in another instance of the same test case.
**assert_raise **is used to assert that a specific exception will be raised by the code.

These are just a few assertions that we can use in Ruby Test::Unit, but there are many more that you can check out.

Watch this video to learn about some exciting features offered by Playwright, like recording tests, taking screenshots of tests, auto-wait mechanism, and much more.

Check this out: Cross Browser Testing Cloud - Browser & app testing cloud to perform both exploratory and automated testing web across 3000+ different browsers, real devices and operating systems.

What happens when the test fails?

If our assertion fails, we get a very descriptive error message that tells us exactly what went wrong. It will even point out the exact line where this occurred in our test file.

Furthermore, failures also tell us what went wrong and whether anything else worked as expected. It will also provide a stack trace of all methods called since the beginning of the test run so we can find out which method failed by looking at their call stacks.

Let’s have a look at an example of a failure below:

As an example, let’s change one assertion in our example above to have a different value so that we expect a failure.

**Note: **At line 22, Our new assert now reads “Nothing Here” and not “Your Store” — thus, we are setting up our test to fail.

On running this, we get the following:

Interpreting the failure

As we can see on line 23: there’s a failure indicated by the bright red color, and below it, we see that it’s the mismatch between the expected string and the actual string.

We can further see the summary of the failure at the end of the script.

Running Selenium Ruby Tests on Cloud Grid

Many Selenium cloud Grid services are provided. However, it is not easy for the users to choose the best one. Here is a list of some of the main things that people should consider before choosing any particular service.

Supports cross-browser testing — For cross browser testing, you need to have a grid that can be used with any of the latest and legacy browsers. You should also check the list of browsers and browser versions that are supported by any particular cloud solution.
Assures quality — The users should check the reviews and ratings of the cloud solution in order to know whether they work well or not. To assure quality, they should also check whether they are working with experienced staff or not because experienced people can ensure quality testing better than inexperienced ones.
Supports parallel test execution — To do parallel testing, the users should be able to select any number of browsers that they can run at the same time. In the case of cloud grid solution, you will get many options like setting a parallel number of instances or choosing a particular cloud that can create instances that quickly. You can set as many parallels as you want to test your product with multiple browsers simultaneously.
Run in a distributed environment — In order to run such kind of work in a distributed environment, the users should have the ability to choose any number of servers which will be used for running tests on that particular server. They should be able to deploy their scripts on multiple servers in order to do distributed testing.
Easy to use and not complicated — Use a solution that is simple and easy. Any user should be able to use the solution without any difficulty. They should avoid selecting any service that is complicated because it can create a lot of problems for them.
Logging — should be easily visible and readable by the user. It should also store a large number of users’ logs
*Reporting *— The users should make automated reports in order to follow them. They should be able to make the reports automatic. The users should be able to see a lot of information about their work by making them automatic
Scalability — Their cloud grid should have many instances that you can add and delete as per your requirement. The number of instances should also be scalable by which you can add more capacity to your grid if required and shut down the instance if it is not required anymore.
*Security and efficiency *— A good cloud solution provider will have a solid security system set up for the protection of their users’ data. This may include secure logins, firewalls, encrypted data storage, and secure transactions using SSL and similar protocols. A full-time security team will be assigned to monitor any sign of hacking or misuse of data.

Cloud based automated browser testing platforms like LambdaTest allows you to run your scripts using different testing frameworks for example — Selenium, Cypress, Playwright, Puppeteer, Appium, etc., and execute them in multiple browsers at the same time — using a variety of devices on demand.

Playwright is an open-source, cross-browser automation framework that provides e2e testing without the need for any third-party tools. Learn what it is, how to install it, and how we can execute tests using Playwright.

Automation testing tools like LambdaTest provides an online device farm of over 3000+ real devices running real operating systems to perform Selenium Ruby testing at scale. Here’s the glimpse of LambdaTest online Selenium Grid.

Check this out: How To Debug Websites Using developer tools for Safari

You can also subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorials around Selenium testing, Cypress E2E testing, CI/CD, and more.

How to run Selenium Ruby Tests on LambdaTest?

Running your Selenium Ruby test on LambdaTest is very quick and easy. Follow the below mentioned steps to get started:

Login/Register at LambdaTest.
Obtain your LambdaTest credentials by choosing the Automation option and checking the top right corner by clicking Access Key.

3- Generate the desired capabilities using the LambdaTest Desired Capabilities Generator.

Be sure to select Ruby as we are using Ruby for this example. We will use the basic configurations selected for now and discuss the other settings in another tutorial.

4- Export your Username and Access Key in environment variables.

For Linux/macOS: 
export LAMDATEST_USERNAME="YOUR_USERNAME"
export LAMDATEST_ACCESS_KEY="YOUR ACCESS KEY"

For Windows: set LT_USERNAME="YOUR_USERNAME"
set LT_ACCESS_KEY="YOUR ACCESS KEY"

Code Changes to run tests on LambdaTest

In order to run your tests on LambdaTest, you would need to substitute your remote local webdriver with a RemoteWebdriver.

Thus our new changes should be as defined in the code below.

require 'selenium-webdriver'
require 'test-unit'

class EcommerceTests < Test::Unit::TestCase
 def setup
   username= "{LAMBDATEST_USERNAME}"
   accessToken= "{LAMBDATEST_ACCESS_KEY}"
   gridUrl = "hub.lambdatest.com/wd/hub"

   capabilities = {
     'LT:Options' => {
       "user" => username,
       "accessKey" => accessToken,
       "build" => "Ecommerce Test v.1",
       "name" => "Ecommerce Tests",
       "platformName" => "Windows 11"
     },
     "browserName" => "Firefox",
     "browserVersion" => "100.0",
   }


   @my_driver = Selenium::WebDriver.for(:remote,
                                     :url => "https://"+username+":"+accessToken+"@"+gridUrl,
                                     :desired_capabilities => capabilities)
   @url = "https://ecommerce-playground.lambdatest.io/"
   @wait = Selenium::WebDriver::Wait.new(:timeout => 30)

   #get url
   @my_driver.get(@url)

   @my_driver.manage.timeouts.implicit_wait = 30

 end

 def test_search_functionality_should_yield_results

   @wait.until{@my_driver.title.include? "Your Store"}

   search_box = @my_driver.find_element(:name, "search")
   # First test assertion - title has loaded
   assert_equal("Your Store", @my_driver.title.to_s)

   search_box.clear
   search_box.send_keys("phone")
   search_box.submit
   sleep(5)
   search_title = @my_driver.find_element(:xpath, '//*[@id="entry_212456"]/h1').text

   # Second test assertion - title has loaded
   assert_equal("Search - phone", search_title)
 end

 def teardown
   @my_driver.quit
 end

end

**Note: **Remember to replace your **LAMBDATEST_USERNAME **and **LAMBDATEST_ACCESS_KEY **with the ones you obtained after signing up on LambdaTest.

Test Results on LambdaTest

As you can see, the results run on the left tab and will be the most recent run at the top as can be seen below.

We now click the latest version of the Build and we now see the test results for this.

Check this out: Playwright browser testing Tutorial- Getting Started With Playwright Framework

Evaluating the results run on the LambdaTest Dashboard

Here, you can see a video on the left — that shows the test results ran in the LambdaTest dashboard.

In this view, you can check whether your script passed all the executions or not, and you can also check some more parameters related to your test instances such as — Execution Status , Browser View, Browser Version, Device Type, Device Capabilities etc.

All Commands Tab — This shows all the commands that the test script has executed.
Selenium Logs Tab — This shows the logs of the WebDriver — such as configuration, capabilities, etc and would appear as shown below.

You will also see some views and tabs in the Selenium Ruby dashboard that show more details about your test scripts’ full execution overtime process.

You can navigate to the LambdaTest Analytics Dashboard to see performance of your tests. From the Test Summary section you can see the total number of tests passed or failed and from the Test Overview section, you can see the snapshot of consistent tests.

You will also note that there are options to run parallel tests — this will help you save time by running your tests in parallel and using different configurations in the process, which is something that can be covered in a separate article.

Watch this video to learn how to write a basic script with Playwright using functions & selectors and then launch the browser to execute the test.

Check this out: Cypress test Automation Tutorial- E2E Testing with Cypress

Conclusion

Like Java and Python, Ruby is a general-purpose programming language; however, it focuses on simplicity, precision, and productivity. Ruby being an array-based language, is very powerful for specific uses and works particularly well with ordered datasets. Moreover, since Ruby has a shorter learning curve and serves the purpose of a specialized tool for what you need for test automation, it is a preferred choice of many developers.

In this Selenium Ruby tutorial, we have seen how Selenium Ruby can be used for automation testing with code examples. By now, you must be comfortable writing your own Selenium Ruby tests and running them on a cloud Selenium Grid like LambdaTest.