A few months ago we had a long and fiery discussion about technical debt. Even if it’s inevitable, there are some precautions we can take. Using Continuous Inspection to measure test coverage, finds bugs, codesmells and vulnerabilities are some of them.
Everything without installing the project environment and running the application.
What is Continuous Inspection?
Just like Continuous Integration (CI) overlooks the quality of the development flow, Continuous Inspection is a way of keeping quality control over the code. Thanks to SonarQube which is an open-source Continuous Inspection tool, developers can show the quality ratings to the client or project manager without running the app or configuring the environments.
I came across SonarQube a few years ago when I worked on a project for travel industry. There were several development teams and the client insisted on keeping a high code coverage. The project was live, had millions of visitors every day and each bug meant a loss of a significant amount of money. You can imagine that inspecting the quality was our client’s priority.
How to use SonarQube?
It takes two minutes to start with SonarQube. First, you need to download and unzip the distribution and start the server.
# On Windows, execute: C:\sonarqube\bin\windows-x86-xx\StartSonar.bat # On other operating system, execute: /etc/sonarqube/bin/[OS]/sonar.sh console
Then, log in to http://localhost:9000 with System Administrator credentials (admin/admin) and follow the tutorial to analyze your first project.
Piece of cake 🙂
You can also install SonarQube on your own server. This way your entire project team can have access to code statistics in one place.
Setting the SonarQube Scanner
Now that the server is set, we can configure SonarQube Scanner which passes the data to SonarQube. It also gives a few nice setting options.
- ProjectKey – must be unique in a given SonarQube instance
- ProjectName – it’s the name that appears in SonarQube UI e.g.
- ProjectVersion e.g.
- Sources – here we set the address of our SonarQube instance. Remember to replace “\” by “/” on Windows e.g.
sonar.host.url=https://sonarqube.mydomain.com \ sonar.sources=src
sonar.exclusions=**/node_modules/**,**/*.spec.ts,**/*.interface.ts,**/*.module.ts,**/*.d.ts sonar.tests=src sonar.test.inclusions=**/*.spec.ts
- Encoding of the source code – the default is system encoding
- Language of the source code
sonar.language=ts sonar.ts.tslint.configPath=tslint.json sonar.typescript.lcov.reportPaths=coverage/lcov.info
Ok, now we’re all set!
What can you see in the analysis?
There are several factors SonarQube measures and shows on the user dashboard. The good news is that you can see at first glance whether your project is healthy. The slightly worse news is that keeping the high quality of the code is a challenging battle.
Here’s a dashboard with some exemplary projects and their statistics.
What can we see there?
Bugs. Issues raised by SonarQube are on either demonstrably wrong code or code that is more likely not giving the intended behaviour. You can find the trickiest potential bugs from the list defined in the tool and see how severe they are. If you’re curious SonarQube also shows a compliant solution, like the one below.
Vulnerabilities. A great thing is that SonarQube can track the insecurities such as SQL injection, hard-coded passwords and badly managed errors. Wildcard keywords (*) or the world well-known User: admin, Password: admin can be avoided.
Code smells. Every single developer will list you a long litany of the things they hate in other dev’s codes. We call them codesmells. Simply put, code smells show the lack of consistency and conventions in the code which can result in difficult (or impossible!) maintenance or further development. Let me list one of the most common code smells I came across:
- Conditional complexity,
- Inconsistent names (check the about DDD and ubiquitous language as reference),
- Dead code,
But there is much more to look for! Luckily, SonarQube shows how much time is needed to correct the code smells.
Code coverage. It shows how many tests have been written with the information who did and who did not cover the code with tests (yep, we know who to blame). There are no strict rules on how much of test coverage one should write but SonarQube allows us to set the test coverage threshold for a particular project.
All you need to do is to set the accepted code coverage in the Quality Gate. For the sake of this example, I set the accepted code coverage to at least 80%.
Duplications. There’s a golden rule in software development that’s called DRY – don’t repeat yourself. It also means “don’t write the same code twice”. SonarQube analyses the code, looks for repetitions and shows the percentage of the codebase that was not DRY.
How to integrate SonarQube with CI
It’s possible to integrate SonarQube with Bitbucket and to comment every pull request automatically with SonarQube analysis. This would not replace a code review but could help in static analysis. This option is available only for the Bitbucket server version.
There’s an option to integrate SonarQube with the CI flow. I find it extremely useful. You can analyze the code for each branch and check whether it has the expected overall quality. With a CI tool it will automatically upload the result to your server, where everyone will be able to check the quality of the new and the existing code.
Other tools for continuous inspection
In terms of fighting the technical debt, SonarQube could be a good tool to keep an eye on how much technical debt you have in the project. It is a static tool so keep in mind it won’t check the code against the requirements. But it can prevent you from making bugs and adding vulnerabilities.
The statistics SonarQube shows are very clear and it makes sense to check them every two weeks or once a month to be aware of the technical debt. And remember, the bigger the code base, the longer it takes to fight technical debt.