Quality Assurance

This section will review the quality assurance practices we decided to adopt.

Scalafmt

Scalafmt is used to enforce a common code formatting convention across the entire code base, helping the team to have a uniform code style.

The tool is available via an sbt plugin that provides several tasks to format the code or check if the code is formatted properly. Specifically, the scalafmtCheckAll task is used in CI/CD to check if the pushed code is formatted properly; in the case of unformatted code, the workflow fails to prevent the merging of unformatted code.

For more details about the rules we used, please take a look at the .scalafmt.conf configuration file.

Scalafix

Scalafix helps developers automate day-to-day code health checks, spot bad programming practices, and linting the code. We agreed on using all the linting rules.

The tool is available via an sbt plugin which provides a task to check the project. This task is used in CI/CD to enforce the rules and prevent the merging of code if the check spots any kind of problems.

For more details about the rules we used, please take a look at the .scalafix.conf configuration file.

Wartremover

Wartremover, as stated in its site, helps Scala developers write safe and correct software by removing some of the language’s nastier features.

Initially, we agreed on using all the built-in warts; however, during the development, we decided to disable two warts project-wise:

• Overloading: we wanted to overload some simple operators like +, -, etc. to make the code easier to read and less verbose. We agreed that the benefits would outweigh the cons of disabling the wart.
• Equals: this wart proved to be quite limiting with regard to the new ADT syntax in Scala 3. When enabled, it would also reject safe pattern matching on an ADT. Since the use of == was also disabled by a scalafix rule, we decided to remove this wart as it did not provide any additional guarantee.

The tool is available via an sbt plugin which provides some tasks to check the correctness of the project. Again, in CI/CD the task is executed to enforce the code quality and prevent the merging of problematic code.

Scoverage JaCoCo & Codecov

Regarding code coverage, it was initially decided to use Scoverage. However, it is still not fully compatible with Scala 3 yet: the use of Scala 3.2.0-RC1 or higher is required. We tried using Scala 3.2.0-RC2; however, Scoverage kept crashing, apparently due to its current lack of support for macros.

For convenience, we fell back to JaCoCo, which despite not being designed to operate directly with Scala, could still produce an acceptable coverage report. However, we found JaCoCo to be quite underwhelming with the reports sometimes being completely inaccurate or unreliable. Unfortunately, at the time of writing, there are no alternatives to Scoverage and JaCoCo.

The reports generated by JaCoCo are taken over by Codecov, which verifies that for each PRs the coverage does not fall more than 5% and generates graphical reports that are accessible here.

Sonarcloud

Sonarcloud is a useful tool as it can detect various issues in code such as bugs, code smells, code duplication, etc. It has been configured to run at every PR and thus evaluate the quality of the contribution made; in case the PR does not meet the expected quality levels, it is blocked from being merged. The quality rules adopted are the default ones available in Sonarcloud for the Scala language.

The Sonarcloud project report is accessible here.