Accelerating Automation - Too Fast Too Furious: How writing tests to an interface and then implementing the interface with selenium page objects accelerated test automation

Be honest, are you fast enough? As the bi-weekly sprints deliver new changes more and more tests need to be created and existing tests modified. It can increase in complexity over time. We need to write as many tests as possible in a way that makes maintenance achievable and enforces that standards are followed. It turns out that interfaces provide a simple way to do this that is easy to implement, and at the same time we have a way to enforce a standard way of doing things, separate two difficult and not at all similar work tasks (one coding, one testing), and provide a more readable and easier to maintain set of test cases. There's everything to win and nothing to lose! With that, I offer for you the insights along the way, coding practices I followed that are easy to implement, and why I think this is a great way to set up your testing frameworks, either for selenium or even API testing, or both. I will conclude with an example of using BDD approaches to show how you might implement this approach for Cucumber style projects. You won't need a Nissan Skyline GT-R, but I'm not saying you shouldn't have one either ;)

 
 

Outline/Structure of the Talk

  • Story: There's an application that automation has lapsed on. The automated scripts were written five years ago, and were not maintained, and now don't work (although the page objects are still good, as they were used in other projects recently). Too fast too furious: the story of how two automation engineers succeeded in developing 1,000 scripts in 30 days and made the process repeatable! It seems impossible (or improbable?), but at least we won't have to bring down an Argentinian Drug Lord!
  • Problem: We have to re-do thousands of test cases, complicated business rules and patterns of automation.
    • Speed of automating tests is often a problem. Can we call Dominic Toretto to help us out with that? What if 1,000 test cases are created each two-week cycle? Can we keep up?
    • Writing a lot of selenium tests is often tricky, and even though we use Page objects, there's often a lot of repetition of boiler plate code to this and that...
    • A look at the traditional Selenium automation approach: Data-driven scripts and page objects
  • Possible Solution: Bring on the Nitrogen Dioxide! We're about to boost our testing! Designing an interface and re-writing the tests to an interface might give us an advantage:
    • Implementing the interface using preexisting page objects
    • Writing the tests so that the tests describe themselves
    • Improving maintainability
  • Specific Benefits:
    1. The tests are easier to read, since they are written to describe themselves, particularly what they actually validate
    2. The tests are easier to maintain since they are shorter, designed to test one thing
    3. The tests are also faster, since they are small, designed to test one thing, and can be executed in parallel
    4. Separation of two distinct tasks: Writing the code that describes what the test should do, and implementing the interface to provide the Selenium support with page factory objects
    5. Call to Action: Take a look at the standard way the interface was designed and see if you can use this approach on your own projects to accelerate automation. If you do well, maybe you will make enough money to buy a 1970 Plymouth Roadrunner!

This topic will be presented in seven parts with duration as follows:

  1. Review of the Page Object Model/Factory and Utility classes as taught and used in frameworks today: (5 mins)
  2. What are some of the limitations of this approach? (5 mins)
  3. How do interfaces help solve some of the key problems? (5 mins)
  4. What are the limitations of interfaces? (5 mins)
  5. Live example of framework using interfaces (10 mins)
  6. When and how to design your automated tests with interfaces (5 mins)
  7. Questions and Answers (10 mins)

We have experienced some great success using this approach on projects that need to catch up :)

Also, there's no change to how you are already doing things now, only an extension of the same where needed!

Learning Outcome

  1. Automating testing is a large project with many different tasks
  2. We can separate test design from implementation by writing the tests to an interface that will be implemented in another task
  3. An interface can really standardize your tests and separate them from how it actually happens, in this case Selenium based factory objects
  4. Tests written to a standard interface are easier to read and maintain
  5. Thinking only about what the test should do, and doing the implementation later leads to better test design
  6. You can write tests faster since you don't have to worry about how the tests achieve their results at the time of designing the test

Target Audience

Anyone already using Java, Selenium with Page Objects and Data Driven looking for a way to implement tests faster

Prerequisites for Attendees

Enthusiasm for Automated Testing

schedule Submitted 1 year ago

Public Feedback