Automation Testing Podcast Automation

239: Clean Selenium Code Using Linting with Kwo Ding

with Kwo Ding

hands-on test automation architect/consultant with 10 years · experience in software testing

February 3, 2019 Hosted by Joe Colantonio

239: Clean Selenium Code Using Linting with Kwo Ding

About this episode

Today we’ll be test talking with Kwo Ding all about his new Sonar WebDriver Plugin which is a static code analysis tool that helps you to follow best practices for writing WebDriver tests. If you're interested in writing clean Selenium code, you don’t want to miss this episode.

Quotes & Insights from this Test Talk with Kwo Ding

Linting, In my opinion, is that a code analysis. So whenever you write code. So in this case test code, it gets analyzed either you push it to a repository or even instantly while you're writing the code. So basically just analyzing whether you are following good practices or tif there are any bugs in your code while writing.
I was inspired by a talk from Dave Hafner at SauceCon I think at the beginning of this year. Where he talked about flaky flakiness of test and that we should focus more on utilizing tools we have in order to reduce the flakiness of your test
I've seen a lot of test code and been analyzing that and there are so many types of best practices and these are very very good and very valuable because we should follow the best practices. So actually I started to write this plugin just to save myself a lot of time in analyzing test code especially the basic stuff like. Okay. You know you have test classes that contain your test and you have non-test classes such as page objects. For example, they should not contain assertions and there is one of the checks that the plugin is doing. Other things are using implicit and explicit waits and hard hardcoded sleeps and that we should not have done and we should handle it in a better way.
It really started about saving myself a lot of time by getting rid of these basic checks so I don't have to do it manually or look at them manually. So the tool will just give me that feedback and it will produce OK on which line it's not following this best practice. It will give you a compliant code example opposed to the non-compliant code that was detected.
I think it's good to highlight that it's really a gap I've seen in the testing industry that we should aim for more or faster feedback in the SDLC. Because there are so many tools coming out that are similar as in how to execute a test but fewer tools about how to get even faster feedback like static code analysis on test code.