Friends: Unit, Mock, and Sonar. So, I think we’re all familiar with the fact that in large old projects with a lot of business code, we can encounter a small number of tests or even their absence. This can be related to the development culture or the fact that the project was evolving very rapidly. The same situation can await us in startups, where the speed of decision-making is very high, and the demand for delivering new functionality to the client or investor is too quick. In other words, there’s no time for tests; we’ll check it as we go along, or the developer will check it during development. But after a couple of years, there are changes in the staff of employees, and problems arise. For example: A new employee may not fully understand the business requirements. They may simply not be familiar with the business yet. They may not know the specifics of the code or the project, and knowledge may have been lost. I believe that many have encountered at least a service, and in some cases, an entire project with such issues. Let’s take a look at this problem from a business perspective. Here, Robert Martin’s book “Clean Architecture” fits very well, where he demonstrates from the first pages how the development of such software becomes more expensive. In other words, the business still sees a simple application/software, but developers often make mistakes and forget about the “peculiarities” of the code, or the overall features, which leads to a significant increase in development costs. Also, you can find the book on Amazon: Clean Architecture: A Craftsman’s Guide to Software Structure and Design (Robert C. Martin Series) So, where should we start after all? It might be hard to believe, but you don’t need to begin by building a very complex process and meticulously planning every detail. Businesses need solutions that will bring immediate benefits, even if it involves immersing employees in the business. Here’s an excellent example: Let’s consider a service for calculating discounts for a customer with no tests or documentation. This is what we’ll focus on. So, the most basic steps are as follows: Identify the critical area where most errors and issues occur. For instance, calculating discounts for major clients or users whose purchases exceed $25,000 in a month. Describe the algorithm of action — the behavior of the method/function/service. Create documentation that outlines the basic algorithm of actions. Add unit tests and mock tests. Strive to cover the entire algorithm of calculations with tests. If not all business cases are covered, return to step 1. Here, I recommend reading articles about TDD (Test-Driven Development) and BDD (Behavior-Driven Development), which can evolve from this stage. Both approaches have a positive impact on both business and code development. Plugins and Sonar The first step is usually the most challenging, but now, it’s time to help developers with analyzing the code they are currently writing. For this purpose, there is a useful plugin — for IDEA we can download and install sonar as a plugin: SonarQube Analyzer connects the SonarQube server with Intellij Idea products. https://plugins.jetbrains.com/plugin/7238-sonarqube-analyzer?embedable=true Just use it! It’s free! Sonar as a Service The third stage will require more than just the efforts of developers. It will also involve the infrastructure team. So, now we need to set up a full-fledged SonarQube service in the infrastructure and configure integration with it. SonarQube is an open-source platform for continuous inspection of code quality. It is designed to help developers and development teams identify and fix code quality and security issues in their software projects. SonarQube analyzes code for a wide range of programming languages and provides detailed reports and metrics on various aspects of code quality, such as code duplication, code complexity, coding standards compliance, and security vulnerabilities. https://www.sonarsource.com/products/sonarqube/?source=post_page-----da33a8b823b4--------------------------------&embedable=true Usually, we set it up as a standalone service in k8s and add an integration with the ci/cd pipeline. In my case, at the outset, we didn't have time for a full automation of the integration process for the entire build pipeline with this tool, so we did everything manually. Most often, I work with GitLab on projects, and there is a fairly simple instruction for integrating it. https://docs.sonarsource.com/sonarqube/latest/devops-platform-integration/gitlab-integration?embedable=true To make this work effectively, we need to integrate auxiliary plugins or analyzers into our services that will generate reports on how well our code is covered by tests. In the case of Java (and any JVM-like language), you will need to add a plugin for this purpose. <plugin> <groupId>org.jacoco</groupId> <artifactId>jacoco-maven-plugin</artifactId> <version>0.8.11</version> </plugin> After successfully setting up SonarQube as a service, let’s proceed with our first and most basic integration through manual configuration. To begin, go to the top right corner, and select “Create Project.” Write a name and a key: Next, simply follow the instructions, as the tool provides detailed guidance in each step. As an example, let’s go through the process of adding a plugin: After integration, we will have a picture: By default, the threshold may be set at 60–80%, which is quite high for us at this stage. So, let’s navigate to the quality profiles and set it to 20%. This will be a great starting point, considering the fact that many services don’t even have tests in place. Support is available for virtually all languages commonly encountered in projects: https://docs.sonarsource.com/sonarqube/latest/analyzing-source-code/languages/overview/?source=post_page-----da33a8b823b4--------------------------------&embedable=true In conclusion, at the current stage, we have achieved the following: At the very least, critical business functionality is covered by basic tests. Now, before releasing a new version, we can explicitly identify issues and bottlenecks, as well as assess how new code affects business functionality. Developers have a tool that helps them identify and highlight code issues as they write it. In other words, we immediately spot problematic areas if they exist. We are collecting statistics and viewing them in SonarQube, allowing us to assess the quality or degradation of our codebase. Integration with CI/CD automates the data collection process, making it more efficient and reliable. Let’s call it a day! Thanks for your attention, and see you soon! Also published here
