5 tips to stay sane with automation testing

Automation is great in the SQA world, but if not managed well it can get really messy. So how do you stay sane?

If one manages to land a sensible product manager who understands the many felicities of developing a business critical UI automation system it is incumbent upon you, as the “SQA guy” to try to do it the best way possible. So here are some road signs I picked up while navigating this cool neighborhood:

1.  Use the best Unit Test module

I started off with the well trodden and well documented path of Python’s default unittest module. The module is very well adjusted to the Object Oriented ways of the UI Automation. But upon looking into the wonderful pytest and its many wonderful features, (fixtures, smart test grouping, excellent hooks and plugins) I had to go with the small learning curve it accompanies. It was worth the time and trying out these modules before starting the project saved a lot of time.

2.  Break down the page object methods

The solution should follow a simple principle. Leave the testing to the test methods. The dilemma is what the functions mean in the Page objects. Well ideally it should not think in web elements but it should think in what it actually does. Like does a function might be used to log in, and not always sending the password to the web element. Sometimes a function may just mean a lot of complex things done in a single function and it makes sense until you are left with huge heavy functions with many dependencies. So you have to find a balance and make it as granular as possible. A thorough understanding of the business is essential to do break this into sensible chunks.

3.  Xpaths but smart

So the saying goes Xpaths are prone to breaking. Which it does. Copy pasting the full xpath will get you fast result but will leave you with flaky code. So if time permits you have to construct and spend some time on unique CSS attributes, Name and Ids to construct good Xpaths (Or use those attributes by themselves). The use of recorders maybe helpful in granular cases. Relative xpaths are quick and better solutions as the time is constrained. You have to find the balance to using these and not be shy to provide the full xpath when its time. But you should definitely know when that time is.

4.  The case for using a lightweight IDE

As the code is repetitive and the coding pattern is relatively simple one might make the argument the lighter and much modular IDEs like VSCode and Sublime text might be given a go. The Modular nature and the plugin strengths of the crowd favorite VS Code makes it an obvious choice but the lightness of Sublime text might just suit your style.

5.  Write clean code

Just like any other kind of project it should follow the basic Clean coding tenets. But especially true for aforementioned Single responsibility principle. Avoiding code duplication is also pretty important. And what I found was particularly important was proper use of Comments. You can literally follow the software business to create a cogent story for the automation to make sense.  It could be done even the untrained eye could make sense of the code.