Chapter 4 - Tooling for Test Automation
You’ve defined your strategy for test automation, you’ve put practices in place to build a culture that supports your strategy, you’ve reviewed key concepts on building reliable tests as well as making sure your application can be automated against. Now is a good time to consider the tooling for your test automation project.
In this chapter, we’ll discuss how to choose the right tools for your initiative.
Before choosing your tools, it’s important to consider who will be using them.
If you do not have programmers who will actively contribute to the test automation, then building your own test automation framework may not be a viable option. Remember, test automation is software development. If your idea is that you will have your testers learn how to code and then create a brand new software development project, please realize that this takes quite a bit of investment in education for them. Your organization should provide a massive amount of support for this.
If that seems unrealistic, there are codeless tools on the market which allow your testers to record their scenarios and then execute them as part of regression testing. While programming knowledge is not required, note that you’ll still need to plan for triaging and maintenance as well.
If you’ll have your developers or automation engineers do the automating, then a coded solution is by far a better option. It allows for more control and flexibility.
The bare minimum you need for your test automation project is an interaction tool and a validation tool.
Remember, we have the three levels: unit tests, service tests, and UI tests. Let’s talk about the interaction for each of these levels.
For unit tests and service tests that call into production functions, they should be written in the same programming language and reside in the same project as the production code. The interaction is simply the call to these functions.
For your other tests, you have more options. Service level tests that call into APIs will need to be able to execute the HTTP requests and read through the responses. So, you’ll want to look for a programming language that makes this easy, or libraries that take care of the boiler plate work for you.
For UI tests, you’ll need a navigation library which provides the ability to interact with the HTML elements of your application. Using a tool that supports the programming language that your application is written in is a reasonable idea. However, you should also consider how easy it is to hire for that programming language, should you want to hire more automation engineers; and also consider how widely supported that programming language is by test automation tools. It’s really beneficial to use tools that have an abundance of support and educational resources. So, if your team is using an obscure programming language with limited support and resources, this might not be the best choice for your automation project. Another factor to consider is the browsers and devices you need to run your test automation against, and ensure that the tools you choose are supported for those options.
You’ll also need to include validation libraries. These are tools which will allow you to turn your code into a test which can pass or fail. There are various options for the array of things you need to verify including functional, visual, accessibility, security, etc.
This is the bare minimum that you’ll need for your automation project: a way to execute the tests and a way to verify them.
However, you can certainly make your project more sophisticated by adding a reporting library which shows screenshots and possibly even video of test failures, or the integration of Gherkin scenario files if your team is already practicing Behavior Driven Development. And if your ultimate goal is to run the tests as part of CI, you’ll want to choose tools that allow for this integration.