SonarCloud: Assuring Quality of Tech Projects
Have you ever worked in a group project with other developers? If yes, below are more some elaborated questions:
- Have you ever been given other people’s code but it’s hard to read?
- Have you ever read a code that’s very inconsistent in its syntax?
- Have you ever noticed some unsecure practices within a code?
If your answer is ‘yes’ to some of these questions, there’s a high chance that you’re reading code that haven’t implement quality assurance practices. In this article, I am going to give an overview of these practices and how my team implement it within our PPL project.
Introduction to SonarCloud
Quoting from their official website,
[SonarCloud] enables your team to deliver clean code consistently and efficiently with a code review tool that easily integrates into the cloud DevOps platforms and extend your CI/CD workflow.
SonarCloud is a tool for quality assurance in the cloud workflow and it can be easily integrated through the CI/CD workflow. I am going to show how my team enables SonarCloud for doing analysis of our front-end code in the later part of this article.
Types of issues
Before diving deeper into the implementation of SonarCloud, first we need to know what kind of issues are tracked by SonarCloud.
- Code Smell: a set of common signs which indicate that your code is not good enough and it can slow down the system, making it harder for developers to maintain it. They’re usually not bugs — they don’t stop the program from functioning — but they indicate weaknesses in design, which may slow down software development or increase the risk of bugs or even failures in the future.
- Bug: code that is evidently incorrect or will yield incorrect behavior. These are essentially things which are plainly wrong, and they prevent the correct functioning of the code. For instance, null pointer exceptions, index out of bounds exceptions, or syntax errors, etc.
- Vulnerability: points of weakness that can be exploited by a hacker to compromise a system’s functionality, or perform unauthorized actions in order to steal, alter, or destroy data. These issues indicate that there might be a way for an attacker to exploit your code, causing a big security risk.
Coverage
SonarCloud also show the coverage of our code. Coverage refers to the percentage of lines of our source code that have been covered by automated tests. The higher the coverage, the lesser the chance of having an undetected software bug.
SonarCloud doesn’t actually run tests itself. Instead, it analyzes the results of our own tests that are run on ourcodebase. We typically use a coverage tool in our continuous integration pipeline to generate a coverage report, and then you would integrate SonarCloud into our pipeline to analyze this report, along with the source code itself.
Technical Debts
After knowing the issues and coverage of our code, now we can move on to what we called as ‘technical debt’. Technical debt refers to the implied cost of additional rework caused by choosing an easy or expedited solution now instead of using a better approach that would take longer. Technical debt is measured in terms of “time”.
When we choose to ignore code smells, leave bugs unattended, or disregard software quality, we’re in a way collecting technical debt. This might speed up development in the short term but slows it down in the long run, as our team has to spend time refactoring the code, fixing bugs, or dealing with vulnerabilities.
How My Team Uses Sonarcloud
Setup on workflow
In order to have the analysis shown on SonarCloud, we need to integrate SonarCloud on our workflows. Worry not, it’s not too complicated. We just need to put in the SONAR_TOKEN and run the SonarCloud scan.
name: Build and Test
on:
push:
branches:
- '**'
jobs:
sonarcloud:
name: SonarCloud
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0 # Shallow clones should be disabled for a better relevancy of analysis
- name: Install dependencies
run: npm install
- name: Test and coverage
run: yarn jest --coverage
- name: Check coverage output
run: cat coverage/lcov.info
- name: SonarCloud Scan
uses: SonarSource/sonarcloud-github-action@master
env:
GITHUB_TOKEN: ${{ secrets.GH_TOKEN }} # Needed to get PR information, if any
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}Monitoring performance
Once our analysis is up on the SonarCloud platform, we can start monitoring our app’s performance.
On the picture above, the summary shows some analysis metrics like code coverage, new issues, duplications, and security hotspots. Sure enough, because our team is taking these seriously, we have minimal to no issues on our app :D. But I’ll show you later how SonarCloud can be helpful when there is issues in our code.
Slightly different from the summary before, this is the graph on the Measure sesction. It shows the mapping of our code, in respect to the coverage and technical debts. As mentioned earlier in this article, technical debts should be avoided because we’ll need to pay for it in the future (which we don’t want. stay away from debts folks). If you look on the bottom right of the chart, there’s some part of our code that have more than 15 minutes of technical debts, which we should avoid.
Handling bugs, code smells, and issues
Let’s say we have issues in our app, like this:
SonarCloud is telling that this is an issue, but we’re actually not sure why. We want to know the reason, so we don’t make the same mistakes again in the future. For that, we can move to the ‘Why it this an issue?’ tab.
Now, we know that it’s an issue because the coalescing operator allows a default value when dealing with nulls. Okay, we now the reason of the issues, but not sure how to implement change to remove the issue. Worry not, SonarCloud is kind enough to give us the way to fix it, which is to me pretty explicit and straightforward.
It shows the examples of compliant and noncompliant code, which is really helpful. Often times, we are told about what’s wrong and how to implement the fix, but don’t get clear picture of which one is good and which one is bad. But now we can just follow the example and get clean-code results. Do it for other issues as well and voila! You get an A for your code quality. Who doesn’t love validation? 😜
What’s New in QA
There are many other new tools that can be used to ensure code quality and cleanliness. In this era, everybody talks about Artificial Intelligence. You guess what, it’s also in QA. Currently there are many new tools to do code analysis and quality check using AI. To mention one, there is DeepCode.
DeepCode is an AI-based code review tool that detects bugs and security vulnerabilities in your code. It uses machine learning to learn from millions of code snippets on the web. It provides insights on how to improve code quality, in terms of reducing bugs and vulnerabilities. Deepcode complements traditional static application security testing (SAST) tools very well by providing an additional layer of analysis and a risk assessment based on real-world threat intelligence.
At the end of the day, it is always about making work even simpler for the developer in whatever area they are working on, including static analysis. It’s exciting to see what QA has to say in the future.
That’s it for this article. I will be making more posts like this. So, I would love to hear what you think. Any feedback is welcomed. Cheers!
