239: Clean Selenium Code Using Linting with Kwo Ding

Hit it.

Welcome to the Test Talks podcast, the place to go to geek out on software testing. And now your host whose mission is to help you succeed with test automation, Joe Colantonio.

Hey, it's Joe. And welcome to another episode of Test Talks. Today we're going to speak in with kuoding all about his new Sonar Webdriver plugin, which is a static code analysis tool that helps you follow best practices for writing WebDriver, Selenium or Appium Test. If you're into writing clean selenium code, you don't want to miss this episode. Really excited to have Kuo back on the show. He is a hands on test automation architect and has a ton of experience. He's been focusing on implementing test automation strategies and designs for test infrastructure organizations for all types of applications on web mobile. And I think his latest passion is API test automation. Koh is actually going to be joining us as one of our roundtable experts at Automation Guild, an online conference dedicated 100% to helping you succeed with creating automation Awesomeness. And if you hear this on Sunday, there's still time to register. If you're listening anytime after Wednesday, the event is over and you missed out. So if you haven't already and you're hearing this early enough, make sure to head on over to automationguild.com and register today. Test Talks is sponsored by the fantastic folks at Sports Sauce Labs, the cloud based automated testing platform that eliminates the need to maintain your own Selenium grid and test infrastructure. Try it for free today. Visit testtalks.com and click on the sign up now link under the homepage sponsor section.

Hey Kuo, welcome back to Test Talks.

Hi Jeff, thanks. Great to be on the ontech Test Talks again.

Awesome. So today I'd like to talk about how to improve your webdriver test code by linting as well as other automation awesomeness. But before we get into it, what have you been up to since last time we spoke? Since I think it was episode 172, it's been a year ago so I know you're working on mobile testing. Are you still doing a lot of mobile testing or what's your latest thing that you're into?

Yeah, so the last time we talked was about the mobile test pyramid. So that's all about mobile testing. So actually after that I was more into the web testing and rest API testing.

So I've been more busy with that lately. And yeah, therefore this new plugin I wrote.

Cool. So that's what I'd like to talk about first, I guess there are a few things I like to hit on first about terminology to make sure everyone's on the same page first. What is linting?

Linting? Well, in my opinion it's static code analysis. So whenever you write code, so in this case test code, it gets analyzed either when you push it to a repository or even instantly while you're writing the code. That's also possible. So basically just analyzing whether you're following good practices or you have any bugs in your code while writing it.

Awesome. So the next thing is sonar. I know a lot of people have used sonar, but folks that haven't. What's sonar and what's it used for?

Sonar is an application that does static code analysis for different platforms and languages.

So actually I was looking for, okay, I would like to write a plugin that does this static code analysis for me. But so I was looking at, okay, which tool is like the most like the de facto standard in the industry. So I came across sonar because I encountered this tool almost in, well, large organizations, is almost always there and if not, people are talking about it to integrate it. So.

It'S heavily used for static code analysis. Well, till now, especially for application code.

Very cool. So I guess why do you think linting is important, especially with functional testing? I know a lot of people do it for unit testing, but why functional testing?

Yeah, so actually I was inspired by a talk from Dave Hefner at saucecon, I think at the beginning of this year where he talked about.

Flakiness of test and that we should focus more on utilizing tools we have in order to reduce the flakiness of your test. And that can sometimes be found in the setup of your test code or the quality of your code. So in the testing industry, compared to the application development, we don't have many tools that does static code analysis. So I was focused on webdriver test code and I couldn't find any that was focused on the Java based implementation of Selenium. So that's how I started with this plugin.

All right, so for the folks I don't know, I believe Dave Heffner, like you said, did have a popular session on best practices for Selenium code. And it would be cool that when you check in code it can analyze and make sure you're following best practices or maybe flag certain issues. So how did you bake this into? I guess first, what is the solution? I believe it's a Sonar webdriver plugin. So how do you use it and then what does it do? Once you, you install it or however you configure it. Right.

So this plays a plugin for Sonar, so whenever you have a Sonar server there, you can install it from the marketplace. Got recently accepted in the marketplace, so it's easy to install.

It's also possible to use a tool called sonalint in your idea. For example, I use IntelliJ and then I can just configure a sonalink to point to a local Sonar server. I also have a Docker image where it's really easy to set up a local server if you don't have Sonar running in order to get that fast feedback while you're writing the test script.

So what's the benefit someone would get by using the solution? Can you give us an example how it would be used in a typical workflow for an automation engineer?

Yeah, so I've been like, in my experience, I've seen a lot of test code and been analyzing that and there's so many talks about 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 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 that is one of the checks that the plugin is doing. Other things are usage of implicit and explicit weights and hard coded sleeps that we should not have them and we should handle it in a better way. And also some checks about locators. So you don't want locators that are tied to your page layout. So you rather have a specific attribute or an ID where you locate the element which is much more robust. So if the application changes the layout, it does not break your test. There are simple things like no webdriver commands in your test because they should be in a base page. So this is all really based on best practices. 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 that manually. So, so the tool will just give me that feedback and it will produce okay, on which line it's not following this practice and it will give you.

A compliant code example opposed to the non compliant code that was detected.

So at what point are you prompted? See, I'm writing code in IntelliJ. Is it like in real time or is it once I have the code written, I somehow click on analyze how does it work from that point of view?

Yeah, so if you use Sonarlib, it's actually instantly so when you're writing it. So when you're typing it immediately analyzes it and it will just highlight that piece of code that is.

Not compliant to the check. Also good to mention that each check has a different priority. Some is like an info message, like, okay, maybe, maybe this doesn't seem right. Maybe you should try it in a different way or think like a hard code to sleep. It's really like a critical issue. You should not do that. So it will also tell you what you can do with this feedback.

Awesome. So how customizable is it? I know a lot of people get upset when you say best practices. They say there are only good practices. So say someone doesn't agree with the way you rank something. Can someone customize their their instance of this plugin?

Yeah, in Sony you can alter it. But one of the reasons why I made it open source is to get the feedback from the community and make the rules like really, really good. Because currently it's an opinionated implementation but you can toggle those priorities of the rules to your situation. But still, yeah, I think many more rules can be added and hopefully that will come when more people are using this plugin.

Why do you think it's important to have these types of tools in your software development lifecycle?

I think it's good to highlight that.

It'S really like a gap I see in the testing industry that we should aim for more or faster feedback.

In the STLC because there are so many tools coming out that are similar as in how to execute the test, but fewer tools about how to get even faster feedback like static code analysis on test code.

So Karl, I think it's been out for two weeks now. Maybe I'm wrong, maybe it's been longer or less. But based on how long it's been, have you got any feedback and you've taken that feedback and baked it back into the plugin or people have started contributing?

Not so much actively on the project itself, but I do get plugin like face to face for people I know running a project with this plugin and see what comes out comes out of it. And then with the script discussions about okay, should we improve this rule or is it very specific to your situation? I think these discussions are very healthy. There is currently one issue with the plugin with the sonar version, currently in the middle of fixing that one, so it should be more compatible with also older versions. But yeah, I'm looking Forward to more feedback. But again, I really started this just for myself, to save me a lot of time and hopefully it can help others as well.

I have a user case in mind. Let me run it by you, see if this is what it's good for right now. I say this a lot. I have eight to 10 sprint teams and they all write their own code on their own teams, but then there's code reviews and they always mess it up. They never get it right, so they always have to put me on. I need to look at it. I never have time. I'll miss the things. So it's almost like this is like a pre check before code review that can, as someone's coding upfront in real time, tell them, hey, you probably want to change that because this is not a good practice and it's going to get flagged in a code review. So it should save you time overall because less issues will creep into the code base in production. Is that correct?

Yeah. So basically you can utilize the SummerLink for instance, feedback, or you can also configure it on your CI pipeline. So whenever you commit something I build will run and scan the code and then you can say, okay, based on this, I don't want any critical issues during this build, so it cannot be merged. So it can really.

Save you a lot of time. But also be careful about the rules because in each situation, sometimes you're not that applicable or you want to change the priority. So you don't want the tool to be like an annoying thing. Right. It needs to help you achieve the goal. As in fast feedback and getting rid of some basic checks that you don't have to do manually.

Yeah, I like to be annoying though, sometimes to people. So this will be annoying.

Yeah, when a tool is annoying, it's a bit different than a person.

All right, so how hard is it to implement in an existing code base? Do you have to set up your project a certain way for this to work? If someone's using say cucumber with Java, would this work? It doesn't matter as long as you're using Java behind the scenes. Yeah.

So it's based on the. So any slim test code that's based on the Java, it will work. And it also supports the Cucumber, the cucumber plugin. But yeah, maybe if people are using other frameworks as well, you can add that check as well. But basically it looks at some annotations whether to determine whether it's a test class or non test class. Yeah, Just to give you an Example.

Say someone wants to get started with it. It sounds like it's what's the quickest way someone can get up and running with the Sonar WebDriver plugin?

Yeah. So let's say you don't have experience with sonar or looking at sonar records. I would say just run the docker image that is on the readme just with one command. You will have the Sonar server running together with the plugin already installed. With that you can run a command in the root of your project to scan the project and see the result. I would say next up would be checking out the Sonar link that's just pointing to your server. So in this case the local host URL and then select the Sonar web driver check and then you're good to go.

So I think this is an awesome idea. How hard would it be for someone to start contributing or helping out?

Well, I think it's pretty easy.

But honestly it took me quite some time to to understand how this Sonar plugin works because the documentation is quite limited. But.

Basically it's test driven. So you write the non compliant test class or example, then you define your check or your rule that scans this test file and you mark on which line in your example is non compliant and based on that it will run a unit test and if that passes, that's actually the implementation of the check. Also some additional information or documentation for Sonar for the reporting. So when you get the feedback, okay, my code is non compliant. I mean the examples that you get back, that's the documentation that comes with each check. But yeah, if people are a bit lost to contribute, just contact me and I'll walk you through.

So I know you did mention it works with Java and Selenium. How about Appium?

Yeah, so actually it's actually based on the WebDriver API, so it should work with Appian as well. But I know that Appian uses some very specific mobile classes, so I think this is one of the areas that it can be extended to. It doesn't mean that the current checks does not work with Appium test code. I mean it should work with that. But I think for example, like locators, there are more locator strategies when you have Appium test code, such as by Accessibility id, stuff like that. These things can be added to the plugin.

I'm always interested in new shiny things. I know this is fairly new, but what's even newer? Is there anything on your roadmap that you like to implement later down the road that was just too much to get on the first iteration.

Well actually it's been quite some iterations to get this first version going because first I started with just a few basic checks and then I thought okay.

This is not enough to have like a complete plugin. So now I really have like the locators check and also like whether an ID locator is valid. So it's a quite good base. So yeah, looking into the appkim extension would be something and yeah, maybe other languages I would like to explore because Sonar is not Java language bound so it can also support like JavaScript or TypeScript. That's something I'd like to like to explore. I think this is really a an area in the testing industry that is quite new as in we have so many good testers to perform the testing but not so much as in to analyze the code while you write it. So I think this is something we should or should get more traction in the industry.

Like I said, I really love this idea and I hope it really takes off. Have you got any feedback from Steve Hefner or Jonathan Lips on either Dave's vision that he had originally or Jonathan from the Appian point of view?

Yeah, so I talked to Dave Hefner and I gave him a walkthrough through this plugin and he really liked it. He thinks someone should work on it because this is a topic that is not fully utilized in the industry yet. And I totally agree. He also had some feedback about the checks I implemented, so I improved them back then. So yeah, it's always good to hear from this Selenium Ninja. That is a valuable plugin.

Very cool. So just a random question, I was on your twitter feed and I noticed you had a Tapster robot. Have you done anything with that in real world testing scenarios?

Well, actually it's a very good marketing robot actually if you just want to show people what you can do with automation, it's a great starter. So what I did is just actually using Dave Hefner's Internet testing application and using the Tapster robot to log in using some form. So that was pretty neat and a good demo. So sometimes I just automate to show people what you can do with test automation and that's really a a great conversation starter to talk about tess summation and what it can do in your situation.

Okay, quote before we go, is there one piece of actionable advice you can give someone to improve their linting or automation testing efforts in general? And let us know the best way to find contact you or to learn more about the Sonar webdriver plugin.

Yeah, so Give the Sonar WebDriver plugin a go by either just firing up the Docker image or install it from the marketplace on your existing Sonar server.

You can contact me through my Twitter handle or on LinkedIn.

Thank you Kuo for your linting Sonar Automation awesomeness Links to everything of value we covered in this episode. Head on over to testtalks.com 2000 and while you're there, make sure to click on that. Sign up for our free trial link under the Exclusive Sponsor section to learn all about Sauce Labs awesome products and services. So that's it for this episode of Test Talks. I'm Joe and my mission is to help you succeed with creating Automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Talks podcast. Head on over to www.testtalks.com for full show notes, amazing blog articles, and other automation awesomeness.