<\/p>\n
The Problem<\/strong><\/p>\n If you\u2019re new to automated web testing<\/a> there\u2019s only a few things you need to know to become effective quickly. But unless someone tells you what they are you could easily head down the wrong path and end up wasting time on things which will yield very few results.<\/p>\n <\/p>\n A Solution<\/strong><\/p>\n By learning the fundamentals of Selenium<\/a> (a popular free and open-source browser automation tool), you can be up and running with cross-browser automated web tests rather quickly. And when combined with a third-party automated visual testing solution like Applitools Eyes<\/a>, you can have an impressively high amount of test coverage with surprisingly little effort.<\/p>\n An Example<\/strong><\/p>\n Selenium is built to mimic human action and it works with two pieces of information to do it: the element on the page you want to interact with and the action you want to take on that element.<\/p>\n If we take a common example like login for a website, here are the actions Selenium would take to step through it like a user would:<\/p>\n Let\u2019s take the login example<\/a> found on the-internet<\/a> and write a Selenium test for it. Let\u2019s use a scripting language (e.g., Ruby<\/a>), since it is very approachable and reads a lot like English. And we\u2019ll use RSpec<\/a>, which is another open source library. It will enable us to organize our tests easily and perform repeatable actions before and after each test.<\/p>\n Here is what the initial Selenium test looks like once written:<\/p>\n NOTE:<\/strong> RSpec<\/a> has some syntax that is worth pointing out. A test case starts with the word At the top of the file we pull in the Selenium Ruby bindings (e.g., Next, we create our login test and fill it with our Selenium commands (which all work using the The first command of the test visits the login page with If we save this file and run it (e.g., The Eyes Have It<\/strong><\/p>\n NOTE:<\/strong> To use Applitools Eyes you need to grab a free account<\/strong> from here<\/a> (no credit card required).<\/p><\/blockquote>\n In order to incorporate Applitools Eyes into our test, we first need to make some modifications to our test setup and teardown.<\/p>\n Once we pull in the Applitools Eyes Ruby SDK (e.g., NOTE:<\/strong> In this example the API key is being passed through an environment variable. You can just as easily hard-code your API key value here.<\/p><\/blockquote>\n Now we\u2019re ready to add some visual checks to our test so we can verify that our application works as intended (and verify that the page renders correctly).<\/p>\n With the Expected Behavior<\/strong><\/p>\n When you save this file and run it (e.g., If Applitools Eyes finds a visual anomaly it will fail the test and provide a URL to the test results in the console output. When viewing the results in Applitools Eyes you can choose to accept or reject the results, which will impact the way Eyes validates the test going forward.<\/p>\n NOTE:<\/strong> A new test in Applitoosl Eyes will fail and prompt you to view the results. It\u2019s recommended that you review the results, but it\u2019s not mandatory. The results will automatically be saved as a baseline image for subsequent runs.<\/p><\/blockquote>\n A Small Bit of Cleanup<\/strong><\/p>\n In order to make this example useful for more than one test, you need to make a small tweak to your test setup.<\/p>\n Within RSpec you can access each test in the Now when you add another test to this file the name will be dynamically passed to Applitools Eyes.<\/p>\n Outro<\/strong><\/p>\n By combining your Selenium tests with an automated visual testing solution you are armed with a powerful combination that gives you a staggering level of coverage (e.g., hundreds of assertions) for only a few lines of code. And as a bonus you\u2019ve automated something that many people think can only be done manually (and as a result tends to get relegated to the end of a software development cycle) \u2013 moving you and your team one massive step closer to Continuous Delivery<\/a>. Bravo!<\/p>\n In PART 2 of this series: \u201cHow To Run Your Automated Web Tests From Any Browser\u201d<\/a>, I\u2019ll show you how to run your tests against whatever browser and operating system combination you need.<\/strong><\/p>\n You can read the third and final post in this series: \u201cAutomating Your Test Runs with Continuous Integration\u201d<\/a>.<\/strong><\/p>\n To read more about Applitools\u2019 visual UI testing and<\/span> Application Visual Management<\/span><\/a> (AVM) solutions, check out the<\/span> resources<\/span><\/a> section on the Applitools website. To get started with Applitools, request a<\/span> demo<\/span><\/a> or<\/span> sign up<\/span><\/a> for a free Applitools account.<\/span><\/p>\n\n
\n\n# filename: login_spec.rb\n\nrequire 'selenium-webdriver'\n\ndescribe 'Login' do\n\n before(:each) do\n @driver = Selenium::WebDriver.for :firefox\n end\n\n after(:each) do\n @driver.quit\n end\n\n it 'succeeded' do\n @driver.get 'http:\/\/the-internet.herokuapp.com\/login'\n @driver.find_element(id: 'username').send_keys 'tomssmith'\n @driver.find_element(id: 'password').send_keys 'SuperSecretPassword!'\n @driver.find_element(css: 'button').click\n end\n \n end\n\n<\/code><\/pre>\ndescribe<\/code>, tests start with the word it<\/code> followed by the test name (e.g., it 'succeeded' do`<\/code>), and you can specify actions to occur before and after each test with before(:each)<\/code> and after(:each)<\/code>. The words do<\/code> and end<\/code> are Ruby code which signify the beginning and end of a chunk of code (a.k.a. a block). And test files in RSpec are known as \u201cspecs\u201d, which need to end with _spec.rb<\/code> in the filename (e.g., login_spec.rb<\/code>).<\/p><\/blockquote>\nrequire 'selenium-webdriver'<\/code>) and declare our test case (e.g., describe 'Login' do<\/code>). Before each test we will create an instance of Firefox and store it in an instance variable to be used during and after our test (e.g., @driver = Selenium::WebDriver.for :firefox<\/code>). After each test we will close the browser (e.g., @driver.quit<\/code>).<\/p>\n@driver<\/code> variable created in before(:each)<\/code>).<\/p>\n.get<\/code> followed by the URL as a string (e.g., 'http:\/\/the-internet.herokuapp.com'<\/code>). We then interact with the login form on the page by finding the username input field with .find_element<\/code> and a locator for the element (e.g., (id: 'username')<\/code>) along with the action we want to take (e.g., .send_keys 'tomsmith'<\/code>). And we repeat the same approach again for the password field (e.g., @driver.find_element(id: 'password').send_keys 'SuperSecretPassword!'<\/code>). For the last command we issue one more .find_element<\/code> to find the submit button (e.g., (css: 'button')<\/code>) and click it with .click<\/code>.<\/p>\nrspec login_spec.rb<\/code> from the command-line), it will open the browser and complete the login on the page. But it wouldn\u2019t tell us if the application behaved as expected. To handle this we need to add in automated visual checks with Applitools Eyes<\/a>.<\/p>\n\n\n# filename: login_spec.rb\n\nrequire 'selenium-webdriver'\nrequire 'eyes_selenium'\n\ndescribe 'Login' do\n\n before(:each) do\n @browser = Selenium::WebDriver.for :firefox\n @eyes = Applitools::Eyes.new\n @eyes.api_key = ENV['APPLITOOLS_API_KEY']\n @driver = @eyes.open(app_name: 'the-internet', test_name: 'login', driver: @browser)\n end\n# ...\n after(:each) do\n @eyes.abort_if_not_closed\n @driver.quit\n end\n# ...\n\n<\/code><\/pre>\nrequire 'eyes_selenium'<\/code>) we update our test setup (e.g., before(:each)<\/code>) by creating an instance of Applitools Eyes (storing it in another instance variable for later use), specifying our API key, and starting an Applitools Eyes session (which requires the name of the app, the name of the test, and the Selenium instance). After each test we make sure to abort the Eyes session if it was unable to close properly (e.g., @eyes.abort_if_not_closed<\/code>) \u2013 more on that soon. And we do this before destroying the Selenium instance (since the Eyes instance relies on Selenium).<\/p>\n\n\n# ...\n it 'succeeded' do\n @driver.get 'http:\/\/the-internet.herokuapp.com\/login'\n @eyes.check_window('Login Page')\n @driver.find_element(id: 'username').send_keys 'tomsmith'\n @driver.find_element(id: 'password').send_keys 'SuperSecretPassword!'\n @driver.find_element(css: 'button').click\n @eyes.check_window('Logged In')\n @eyes.close\n end\n\nend\n<\/code><\/pre>\n@eyes.check_window<\/code> command we\u2019re performing visual checks. We can specify a value with it or not (e.g., ('Login Page')<\/code>, ('Logged In')<\/code>). The value is optional, but it will appear in the test results in Applitools Eyes. It could add a helpful narrative for you (or other people on your team) to follow along with what the test was doing when the results are reviewed after the fact.<\/p>\n@eyes.close<\/code> ends the Applitools Eyes session and triggers the final comparison of the visual checks.<\/p>\nrspec login_spec.rb<\/code> from the command-line) here is what will happen:<\/p>\n\n
\n# filename: login_spec.rb\n# ...\n before(:each) do |example|\n @browser = Selenium::WebDriver.for :firefox\n @eyes = Applitools::Eyes.new\n @eyes.api_key = ENV['APPLITOOLS_API_KEY']\n @driver = @eyes.open(app_name: 'the-internet', test_name: example.full_description, driver: @browser)\n end\n# ...\n<\/code><\/pre>\nbefore(:each)<\/code> by adding a block variable (e.g.,before(:each) do |example|<\/code>). You can then put it to use @eyes.open<\/code> when specifying the test name (e.g., test_name: example.full_description<\/code>).<\/p>\n
![\"Increase](\"https:\/\/app14743.cloudwayssites.com\/wp-content\/uploads\/2016\/12\/Automation_expert_coverage-1.png\")
<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"