taken from https://docs.konsist.lemonappdev.com/

In my last article, I wrote about my first experience with Akkurate, a new validation library for Kotlin. But that’s not the only new library that was introduced recently which has aroused my interest. Therefore it’s time to give insights into the first experience with another newcomer – Konsist.

So what is Konsist?

The official documentation gives a good and concise explanation of its purpose and I can not sum it up better.

Konsist is a static code analyzer for the Kotlin language. It is compatible 
with various Kotlin projects including Android projects, Spring projects, 
and Kotlin Multiplatform projects.
Konsist simplifies the process of maintaining codebase consistency by 
upholding coding conventions and safeguarding the project's architecture. 
It empowers developers to create consistency checks through unit tests, which
can be run during pull request (PR) reviews for verification.
(taken from https://docs.konsist.lemonappdev.com/getting-started/readme)

dependencies{
  testImplementation("com.lemonappdev:konsist:0.12.2")
}

Konsist.scopeFromProduction(moduleName = "MyModule", )

Konsist.scopeFromPackage(packagee = "com.poisonedyouth.exmple", moduleName = "MyModule")

Konsist.scopeFromFile(path = "src/main/kotlin/com/poisonedyouth/example/MyFile.kt")

The next step is to select what declarations I want to analyze. Let me show that in an example. I use multiple declarations in a single file called Test.kt with the below content:

import org.springframework.stereotype.Controller

class TestClass{
    
}

class OtherTestClass{

}

interface TestInterface{
    
}

@Controller
annotation class TestAnnotation{
    
}

Depending on the declaration selector I get a different result.

// This prints "Test.kt" 
Konsist.scopeFromFile("src/main/kotlin/com/poisonedyouth/example/Test.kt")
   .files
   .print()

// This prints "org.springframework.stereotype.Controller"
Konsist.scopeFromFile("accounting/src/main/kotlin/com/sevdesk/accounting/booking/taxinformation/api/impl/Test.kt")
   .imports
   .print()

// This prints "TestInterface"
Konsist.scopeFromFile("accounting/src/main/kotlin/com/sevdesk/accounting/booking/taxinformation/api/impl/Test.kt")
   .interfaces
   .print()

// This prints "TestClass, OtherTestClass, TestAnnotation"
Konsist.scopeFromFile("accounting/src/main/kotlin/com/sevdesk/accounting/booking/taxinformation/api/impl/Test.kt")
   .classes
   .print()

With this, depending on the requirement I can limit the elements that are processed to the ones I need. The above examples are just a small part of what is possible. You can have a look at the documentation about what is possible.

As soon as the declarations to process are filtered I can start by asserting for the expected conditions.

In the following part, I will show different real examples I’m currently using in my applications, which should show what is possible with Konsist (even in this early stage).

Runtime Optimization

Most of my tests that are part of a single test class are using the same scope as input, so it makes sense to move the configuration to the companion object of the test class.

companion object {
     val projectScope = Konsist.scopeFromProduction(moduleName = module)
}

With this, every test can use the projectScope property. This improves the runtime of executing all the tests in one class dramatically (10 test methods – without static configuration ~5 seconds, with static configuration < 1 second).

Imports

The first use case that I have in all my applications is to check files for imports. Either an expected one should be available or a specified one should not be available. In e

// The specified imports are available
Konsist.scopeFromProduction()
   .files
   .withPackage("com.poisonedyouth.example.port..")
   .assert {
       it.hasImportWithName(
          "com.poisonedyouth.example.domain.."
       )
    }

// The specified imports are not available
Konsist.scopeFromProduction()
   .files
   .withPackage("com.poisonedyouth.example.common..")
   .assertNot {
       it.hasImportWithName(
          "com.poisonedyouth.example.domain.."
          "org.springframework...",
       )
    }

There is just one limitation with the given built-in hasImportWithName – function, if the file has no imports at all, it will fail. There are some use cases where this is leading to unwanted issues. But that’s no problem, I just can write my own extension function that is working as expected.

private fun KoFileDeclaration.hasImportWithNameOrNone(vararg names: String): Boolean {
    if (this.imports.isEmpty()) {
        return true
    }
    return imports.all { import ->
        names.any { name ->
            LocationUtil.resideInLocation(name, import.name)
        }
    }
}

This is just one example for how easy the built-in functionality can be extended in case they don’t cover all the personal needs. Because the project is in an early stage of development, the probability that missing built-in functionality is added in one of the next releases is relatively high. Just contact the maintainers in either the official slack channel (#konsist as part of kotlinlang.slack.com) or directly in the github repository.

Data Class

Data classes are designed to be immutable. All primary constructor parameters should use val instead of var, what makes it easier to deal with the state, especially in multithreaded environments. Instead of changing the internal state of an instance from outside the copy – constructor should be used to create a new instance. To check that there is no var used, the below declaration can be used:

Konsist.scopeFromProduction()
   .classes()
   .withModifier(KoModifier.DATA)
   .properties(includeNested = true, includeLocal = true)
   .assert{
      it.hasValModifier
   }

The withModifier() – function can be used to limit the classes that are included in the assertion block. There are a lot of options possible. Another use-case for data classes is to check that there is no init – block used. As long as try-catch-throw is used for handling exception the init – block is the main place for validation of the input, to only allow valid domain models. Because meanwhile Either is used for exception handling in most of my projects, and this is no longer possible. The init – block cannot return an Either type. So to not by mistake forget to remove this blocks, I can write the following check:

Konsist.scopeFromProduction()
   .classes(includeNested = true)
   .withModifier(KoModifier.DATA)
   .assert {
      it.initBlocks.isEmpty()
   }

Data classes automatically implement the equals() and hashCode() function including the primary constructor parameters. But it is not always possible to use data classes to model domain models. Especially when dealing with Either exception handling, it can be necessary to use a class with a private constructor and use a factory method for creation of objects. As soon as a normal class is used, which should be comparable later or is put to collections (especially sets) it is necessary to implement equals() and hashCode() manually (see https://kt.academy/article/ek-equals for details about why this is important).

To be sure that always both methods are implemented I can use the below check that shows violations for all classes that only implement one of the both methods.

Konsist.scopeFromProduction()
  .classes(includeNested = true)
  .assertNot {
      it.countFunctions { functionDeclaration ->
          functionDeclaration.name in listOf("equals", "hashCode")
      } == 1
  }

Annotations

Another category of checks that can be implemented are related to annotations. Especially when working in the Spring / Spring Boot ecosystem annotations play an important role and occur all over the project.

It is easy to enforce the naming of Spring components. If it is intended that all rest controller components (marked by the annotation) also contain a “Controller” suffix, this can be achieved by below snippet:

Konsist.scopeFromProduction()
  .classes(includeNested = true)
  .withAnnotationOf(RestController::class)
  .assert {
      it.name.endsWith("Controller")
  }

The same can also be done for the @Service, @Repository or other used annotations.

Even though I use SpringBoot as framework I still want the domain to be free of framework-specific code. So I want to check that inside the domain package there are no Spring specific annotations used.

Konsist.scopeFromProduction()
    .classes(includeNested = true)
    .withPackage("com.poisonedyouth.example.domain..")
    .assertNot { 
        it.hasAnnotationOf(
           Configuration::class, 
           Service::class, 
           Repository::class
        )
     }

val interfaces = projectScope
    .interfaces()
    .map { it.name }
val abstractClasses = projectScope
    .classes()
    .withModifier(KoModifier.ABSTRACT)
    .map{ it.name}
val expectedComponents = interfaces + abstractClasses


Konsist.scopeFromProduction()
     .classes()
     .withAnnotationOf(
         RestController::class,
         Service::class,
         Repository::class,
       )
      .assert {
           it.primaryConstructor!!.parameters.all { parameter ->
                    parameter.hasType { type ->
                        expectedComponents.any { name ->
                            type.sourceType == name
                        }
                    }
            }
      }

Maybe with one of the next releases a more elegant solution will be possible.

Visibility

When working with multi-module projects with Gradle it is important to define the dependencies between single modules. For having as much independence between modules as possible I can introduce internal APIs. As an example module A provides an API for providing user data that is necessary for module B. Instead of directly using the repository of module A (which couples both modules very tight), module A provides an API that allows to load the data using a contract. Because the repository is visible for module B there is the risk that it is still used beside the API. So to make only the API and its types visible, I can set all other classes to internal. To enforce this also for newly added classes I can add the below check:

Konsist.scopeFromProduction()
  .classes()
  .withPackage("com.poisonedyouth.example.impl..")
  .assert {
      it.modifiers.contains(KoModifier.INTERNAL)
  }

Architecture

Konsist also supports a special requirement for verifying the architecture of applications. The provided functionality can also be achieved by the already described functionality above but it is not such concise.

There is a special function called assertArchitecture(), inside of which I define the layers my application consists of. Each layer is identified by a root package. After the definition of the layers I can configure which access between the layers is accepted. With this test I verify that e.g. a domain model is not by mistake directly used in the adapter (because I want to use a mapping of types between all layers).

Konsist.scopeFromProduction()
  .assertArchitecture {
     val domain = Layer("domain", "com.poisonedyouth.example.domain..")
     val adapter = Layer("adapter", "com.poisonedyouth.example.adapter..")
     val port = Layer("port", "com.poisonedyouth.example.port..")
     val common = Layer("common", "com.poisonedyouth.example.common..")

     domain.dependsOn(common)
     adapter.dependsOn(common, port)
     port.dependsOn(domain, common)
     common.dependsOnNothing()
  }

This article was previously published on proandroiddev.com