Would your Selenium tests achieve a passing grade if they were judged based on their code quality?
If you could, how would you grade your Selenium tests and avoid writing bad code?
Do you have a way to automatically flag issues that are known to be bad Selenium automation practices?
Wouldn’t be great to have a repeatable, quantifiable way to write better test code, leading to more reliable Selenium tests?
Grading Your Selenium Automated Tests
In his Automation Guild 2017 session titled How to Grade Your Selenium Tests, Dave Haeffner outlined a way to help ensure you and your teams are creating well-written Selenium tests.
Dave discussed what makes a test “bad” or “good,” and suggested a rubric for grading your tests, page objects and locator strategies.
Dave also challenged folks to focus more on utilizing the tools they have in order to reduce the flakiness of our tests.
Sonar Selenium WebDriver Plugin
In a recent TestTalks interview, Kwo Ding mentioned Dave’s talk and how it inspired him to create a Sonar plugin that can be used to remedy a host of issues before your tests are introduced into your main code base.
The Sonar WebDriver Plugin Kwo has developed is a static code analysis tool that helps the user to follow best practices for writing WebDriver tests.
Some of you may already be familiar with tools that help developers find issues in their unit tests, but may not have been aware it was even possible for functional tests.
Compared developers, we don't have many tools in the testing industry that do static code analysis specifically for WebDriver test code.
Thanks to Kwo, there is one now. It’s a Java-based code analysis tool that uses a technique known as linting.
Linting Your Selenium Code For Bad Practices
Linting is when a lint or linter tool program runs a process that analyzes code for potential errors and issues.
Whenever you write test code, it gets analyzed either when you push it to a repository or instantly while you're writing it. That’s pretty cool because it’s also analyzing whether or not you are following good practices, or whether there are any bugs in the code.
Selenium Sonar Code Review Workflow
You may be asking, “How would you use this plugin in your typical workflow as an automation engineer?”
Like me, you have probably seen a bunch of great conference sessions and read articles on ways to write better Selenium code.
This is great, but if you are bombarded with an abundance of code review of your team’s automation efforts, are you able to catch all the issues?
When you are pressed for time, are you able to write clean code without it needing any refactoring later on?
This plugin can help you with the above scenarios. Kwo was looking to save himself (and all of us) a considerable amount of code analyzation time–especially the basic stuff.
It can help you quickly spot common issues; for instance, if you have classes that contain both test and non-test classes, such as page objects. For example, one good practice is that page objects should not contain assertions, and that’s one of the checks the plugin does automatically for you.
Other bad practices that can creep into your test code have to do with the wait approach you use. Some folks mess up implicit and explicit waits and hardcoded sleeps. Kwo’s plugin will flag poor wait choices and suggest a better way to handle them.
It also scans your code for poor element locator choices you may have used. For instance, you don't want to have locators that are tied to your page layout. It’s better to have a specific attribute or ID to help you locate the element. This type of locator is much more robust, so if the application changes the layout, it won’t break your test.
This is all really based on best practices.
Save time writing better code
The Sonar WebDriver plugin can also save you time by getting rid of these basic checks so you don't have to do them manually. The tool will give you that feedback, and will produce OK or create a warning on any line that may not be following one of the Selenium best practices. If it does find what it considers to be a potential issue, it also will give you a compliant code example to help you fix it.
Another cool feature is that when you’re typing your code in an IDE like IntelliJ it can immediately analyze it, and will simply highlight the piece(s) of code that doesn’t pass its checks.
It's also good to mention that each of the plugin’s checks has a different priority. Some alerts are more like info messages telling you that something doesn’t seem right but may not necessarily be a serious issue, but it will still suggest some things to try in a different way to make your code even better.
Furthermore, if you do something that plainly sucks it will throw a hard error and flag it as a critical issue. So the feedback the tool provides also acts as a guide while you’re creating your code.
Coding Tools for Testers
Based on Kwo’s and my experience, there is definitely a gap in the testing industry that tells us we should aim for more or faster feedback in our SDLC.
Sure…there are a bunch of tools being introduced that can help you execute a test, but there are far less tools that are designed to yield even faster feedback like a static code analysis for test code?
This is why I believe the Kwo Ding’s Sonar WebDriver plugin is a great resource for the automation testing community at large, and one we should all support.
