The past few years have seen a phenomenon of software organizations abandoning traditional release cycles in favor of daily or even hourly deployments. The emergence of a new, rapid software development workflow has raised questions regarding the role of test and QA in a product’s life cycle. When there is no QA phase, can there still be QA? In this talk, Noah Sussman answers that question and more as he delivers an Intro to Selenium and continuous deployment.Continue
In Part 1 we learned how to use Selenium IDE to automate the testing of common actions within the browser. In Part 2 we’ll take a programmatic approach to browser automation using the Selenium Webdriver API and the Page Object Model.
Integrating Selenium Webdriver API calls into your unit tests is easy. If we want to use Webdriver to automate a user searching “Axial Network” on Google, all we have to do is…
from selenium import webdriver
driver = webdriver.Firefox() # Open a Firefox browser
driver.get('http://www.google.com') # Go to page
driver.find_element_by_id('gbqfq').send_keys('Axial Network') # Type search term
driver.find_element_by_id('gbqfb').click() # Click search button
While this example uses Python to perform actions in Firefox, its also possible to use Java, C# or Ruby to perform actions in Chrome, Safari or IE. Selenium IDE test cases can be converted to Webdriver code by going to File > Export Test Case As… > Python 2 (WebDriver). The example here shows the result of converting our test case from Part 1, which tests weather.com’s ability to get the weather in New York.
Introducing the POM
How can we piece together our test cases in a way that produces a flexible and maintainable testing suite? What do we mean by “flexible and maintainable”?
1. One that requires minimal changes when application code changes
2. One that is reusable, in that testing logic can be shared across multiple test cases
3. One that can be run on multiple browsers
This is where the Page Object Model (POM) comes in. The POM is an approach that focuses on modeling all the attributes and actions that comprise each page, then writing test cases that perform those actions and verify results. This approach makes a lot of sense given we are trying to simulate user actions, which can be described in the form of “go to that page and do this, go to this page and do that, and so on”.
As an example lets model a login page…Continue
The challenge with testing is no different than most: allocating resources. Its hard to sacrifice resources for testing at the cost of new features and still feel a sense of accomplishment – especially when such a sacrifice needs to be made every time you release. At Axial we release every day and have come to realize that such sacrifices need to be made consistently in order to maintain a top quality product. We recognized the need to make our testing efforts more reusable. We accomplished this by doing what the corpus does best: build. From this we built Axium, a test automation suite that is easily executed, understood, maintained and configured. This is the first of a series of posts that shows how we built Axium and contains the following independent parts:
1. Selenium – For test automation Continue