PiperKt

Appearance

Quality Assurance & Checks ​

Quality Assurance ​

Quality Assurance (QA) is a process that ensures the quality of software products. It is a systematic process that involves checking whether the software product meets the specified requirements, is free from defects, and is reliable. QA is an essential part of the software development process as it helps to identify and fix bugs and issues before the software product is released to the end-users.

The project QA targets the following areas:

  • Code Testing & Linting
  • Code coverage
  • Documentation

Note: The project QA involves the new developed artifacts. The old parts are integrated as is, adding few tips to improve the quality, described as follows.

Code Testing & Linting ​

Project software artifacts have been tested using various tools and techniques. Here methods and technologies used for testing and linting:

  • Formatter:

    • ktfmt: a Kotlin linter and formatter that helps to maintain a consistent code style across the project. It is by design non-customizable in order to promote consistency. It's been used to format the Kotlin codebase.
    • Spotless: a code formatter that can apply formatting rules to a variety of languages. It's been used to format mainly Typescript and Yaml files.

  • Static code analysis: The project uses Detekt to perform static code analysis on the Kotlin codebase. Detekt is a static code analysis tool for the Kotlin programming language.

  • Architecture Testing: The project follows the Clean Architecture and Domain Driven Design principles. In order to enforce these rules, the architecture is tested by the use of the Konsist, a structural linter (static code analyzer) designed for Kotlin language.

  • Unit Testing: Unit tests are used to test individual components of the software product. It's been used Kotest as the testing framework.

  • Integration Testing: Integration tests are used to test the interaction services and it's dependencies. In addition to Kotest, it's been used TestContainers to provide a lightweight, throwaway instance of a database, message broker, or any other service that the system under test may require.

  • Behavioral Testing: Behavioral tests are used to test the behavior of the software product from the end-user perspective. These tests are written in Gherkin (using Cucumber) language and are executed using the Kotest framework. They are very useful to acceptance tests and to ensure that the software product meets the specified requirements.

Code Coverage ​

Code coverage is a metric that measures the percentage of code that is executed during automated tests.

The project set a minimum code coverage of 50% for the Kotlin codebase. The code coverage is measured per subprojects using Kover running the defined tests in each package.

The project uses Codecov to track the code coverage of the project and publish the results.

Here is the coverage report for the project.

Documentation ​

Code ​

Code documentation is an essential part of the software development process. It helps developers understand the codebase, its components, and how they should work and how to use them.

The project uses Dokka, an API documentation engine for Kotlin, to generate documentation for the Kotlin codebase.

The documentation is generated and published to the GitHub Pages of the project.

REST API ​

API documentation is another essential part of the software development process. This allow developers to understand how to interact with the software product, what endpoints are available, what parameters they should use, and what responses they should expect.

The project uses OpenAPI to describe the REST API of the project. The OpenAPI specifications are generated using the Micronaut OpenApi plugin.

The documentation once generated, is published to the GitHub Pages of the project.

Events API ​

The project uses AsyncAPI to describe the Events API of the project.

The documentation is published to the GitHub Pages of the project.

Quality Control ​

The quality control process, that ensures the rules described above are followed, is performed at least in two phases:

  • Pre-Commit: The quality control process is performed before the code is committed to the repository. This process includes a lightweight set of the checks described above, such as code formatting, static code analysis, and compilation. This allows developers to catch and fix small issues early in the commit process. The team agreed on * avoiding tests execution* in this phase to keep the process fast. This trade-off is acceptable because the tests are executed in the CI/CD pipeline, discussed in the next point.

  • CI/CD Pipeline: The full quality control process is performed in the CI/CD pipeline. This process includes all the checks described above, such as code formatting, static code analysis, unit tests, integration tests, and code coverage. The CI/CD pipeline is triggered on every push to the repository and on every pull request. The pipeline is configured to fail if any of the checks fail, ensuring that the code that is merged into the main branch meets the quality standards. All checks should pass before the code is merged into the main branch.