Best Practices – Inspecting Selenium Tests Code Quality Using SonarQube

Overview:

In the good old days, automation scripts were mostly record and playback! That was because most of the people who were doing automation were manual testers turned into automation engineers. It was rare to see a a good framework for automated testing. Now situation is completely different. Thanks to DevOps process – everyone understands the importance of automated testing. Nowadays, automation engineers use most of the tools available for Dev/SysAdmin to improve the QA process. We use Jenkins, Git, Docker etc.

We follow all the design principles and patterns for writing our selenium scripts to keep our maintenance effort under control and ensure that our test scripts are following certain standards.

In this article, we are going to take a look at SonarQube – a tool continuously inspects the code we push to GitHub/Version control to ensure that our test script quality is good! Using SonarQube for inspecting our automation scripts brings several advantages. Some of them are listed here.

• Raises the code quality
• Detects the duplicate code
• Ensures that Dev coding standards are being followed
• Detects any potential issues with the test scripts / logic issues etc

Setting Up SonarQube:

You can visit the official site and check the install instruction if you do not use Docker. I am going to use Docker! Setting up any tool is now easy with Docker.

• Create a directory
• Under the directory, create a file – docker-compose.yml with below content.

version: "3"
 
services:
  sonarqube:
    image: sonarqube:6.7.1
    container_name: sonarqube
    restart: always
    environment:
      - SONARQUBE_JDBC_USERNAME=sonar
      - SONARQUBE_JDBC_PASSWORD=password1
      - SONARQUBE_JDBC_URL=jdbc:postgresql://db:5432/sonarqube
    ports:
      - "9000:9000"
      - "9092:9092"
    volumes:
      - sonarqube_conf:/opt/sonarqube/conf
      - sonarqube_data:/opt/sonarqube/data
      - sonarqube_extensions:/opt/sonarqube/extensions
      - sonarqube_bundled-plugins:/opt/sonarqube/lib/bundled-plugins
 
  db:
    image: postgres:10.1
    container_name: db
    restart: always
    environment:
      - POSTGRES_USER=sonar
      - POSTGRES_PASSWORD=password1
      - POSTGRES_DB=sonarqube
    volumes:
      - sonarqube_db:/var/lib/postgresql
      - postgresql_data:/var/lib/postgresql/data
 
volumes:
  postgresql_data:
  sonarqube_bundled-plugins:
  sonarqube_conf:
  sonarqube_data:
  sonarqube_db:
  sonarqube_extensions:

• Run the below command

docker-compose up -d

• That command will download all the necessary docker images and bring SonarQube server up and running at port 9000.

• You can login with default username and password.
  • username: admin
  • password: admin
• Create a token for your project. [I am going to inspect this project in GitHub ]

• Select the project language and build tool. In my case it is Java and Maven. As you see, SonarQube supports many other languages like C#, python and JavaScript etc.

• Copy the command which is displayed on the right side.
• Once we copied, you can close that dialog. We would see below screen. We have not analysed any projects so far.

• We need to run the command in the machine where we build our project. Modify the copied command from the previous step, slightly as shown here.
  • SonarQube requires compiled code for Java. So we add the ‘clean compile‘ command
  • If SonarQube is running in a different machine, then update the command with the IP address of the SonarQube machine.
  • We also include our classes under test directory

mvn clean compile \ 
   sonar:sonar \
  -Dsonar.host.url=http://10.11.12.13:9000 \
  -Dsonar.login=4f20ed69e698b9039354e73dd3d81c785eb7fa63
  -Dsonar.test.inclusions=**/*Test*/**

• That’s it. It will compile, inspects the sources and push the results to SonarQube.
• After refreshing the screen, We can see results as shown here.
• Our project is a simple project. Since we have only 2 page objects and 2 test classes, our code is also more or less decent, we do not see much issues here.

• We still have 16 code smells to fix which could take approximately 2 hours of work as per SonarQube
• Click on the ’16’ to see all the ‘code smells’ – In the project I have used, I have many System.out statements which caused these many issues in SonarQube.

• You can click on the links to get more details about the issues and fix all these one by one.
• If you want SonarQube to exclude certain checks like System.our/System.err, you can disable those checks.

• SonarQube has also some good rules for tests! It reports if Thread.Sleep is used anywhere which is very bad practice.

 

• SonarQube also suggests that it is a bad practice to use list.size > 0 to check if the list is empty or not as there is an isEmpty method for this purpose.

• The list issue should be fixed as shown here.

//itemPrice list should not be empty
Assert.assertFalse(itemPrice.isEmpty());

• Once we fix the issues, run the same command once again. Now SonarQube will reinspect your code & automatically close the issues.
• By creating a Jenkins job, we could run this command periodically to inspect our code quality continuously.

Summary:

Our selenium test scripts might not go to production! But it ensures that only high quality product is shipped into Production. As our selenium scripts have big responsibility of verifying the code created by developers, It is important for our test scripts to meet industry quality standards 🙂 SonarQube helps us to meet the code quality.

Happy Testing and Subscribe 🙂