The following example provides the minimum setup for defining and running a single Konsist test.

At a high-level Konsist check is a Unit test following multiple implicit steps.

3 steps are required for a declaration check and 4 steps are required for an architecture check:

Konsist is a structural linter (static code analyzer) designed for Kotlin language. Verifying codebase with Konsist enables development teams to enforce architectural rules and class structures through automated testing.

Konsist offers comprehensive verification capabilities that enable developers to enforce architectural rules and maintain code consistency, thereby improving the readability and maintainability of the code. It's like ArchUnit, but for Kotlin language. Whether you're working on Android, Spring, or Kotlin Multiplatform projects, Konsist has got you covered.

The Konsist API provides developers with the capability to create custom checks through unit tests, customized to align with the project's unique requirements. Additionally, it offers smooth integration with leading testing frameworks, including JUnit4, JUnit5, and Kotest, further streamlining the development process.

Konsist offers two types of checks, namely and , to thoroughly evaluate the codebase.

Declaration Checks

The first type involves declaration checks, where custom tests are created to identify common issues and violations at the declaration level (classes, functions, properties, etc.). These cover various aspects such as class naming, package structure, visibility modifiers, presence of annotations, etc. Here are a few ideas of things to check:

• Every child class extending ViewModel must have ViewModel suffix

• Classes with the @Repository annotation should reside in ..repository.. package

• Every class constructor has alphabetically ordered parameters

Here is a sample test that verifies if every use case class resides in domain.usecase package:

ArchitecturalChecks

The second type of revolves around architecture boundaries - they are intended to maintain the separation of concerns between layers.

Consider this simple 3 layer of :

• The domain layer is independent

• The data layer depends on domain layer

• The presentation layer depends on domain

Here is a Konsist test that verifies if Clean Architecture dependency requirements are valid:

Summary

By utilizing Konsist, teams can be confident that their Kotlin codebase remains standardized and aligned with best practices, making code reviews more efficient and code maintenance smoother.

Add Maven Central Repository

Add mavenCentral repository:

Add Konsist Dependency

The Konsist logo can be found in the of the main repository.

Our in JIRA. If you want to join say hello at Slack channel. If you are working on a ticket make sure to get the JIRA access, assign it to yourself, and update the ticket status to In Progress).

In Konsist all checks are tailored for a given project.

As the project grows additional checks can be defined to enforce various checks eg. layer boundaries, package structure, class naming, and more. The following sections contain a set of sample checks to give an idea of what is achievable with Konsist.

Most of the snippets are wrapped as JUnit tests, however, these snippets can be easily wrapped in the kotest tests.

Konsist is compatible with all types of Kotlin projects including Android, Spring, and Kotlin Multiplatform projects.

Konsist works with popular testing frameworks executing Kotlin code. Konsist has first-class support for JUni4, JUnit5, and Kotest.

Konsist is compatible with popular build systems such as Gradle and Maven.

The Java 8 is a minimum Java version required to run Konsist.

Konsist is backwards compatible with Kotlin 1.8.x ( since Konsist 0.17.0 ).

Dependencies

Konsist depends on:

• org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.6.4 (minimal coroutine usage make Konsist compatible with newer coroutines versions)

• org.jetbrains.kotlin:kotlin-compiler-embeddable:2.0.20

Browse the current list of contributors directly on GitHub.

📢 Let us know about issues you face and improvements you would like to see. Your feedback is crucial in shaping the future of Konsist. Whether it's a suggestion for improvement, a bug report, or a question about usage, we're here to listen and help.

Share your thoughts on the #konsist channel to get help or start a new GitHub discussion 💬 for bug reports, issues, and feature requests.

Package wildcard syntax is used to provide a more flexible way of querying packages.

The two dots (..) means any zero or more packages eg. all classes reside in a package starting with com.app:

    Konsist
        .scopeFromProject()
        .classes()
        .assertTrue { it.resideInPackages("com.app..") }
        
// com.app.data - valid  
// com.app.data.repository - valid  
// com.data - invalid
// com - invalid
        

Package wildcard syntax can be used multiple times inside the string argument. Here all interfaces reside in a package logger prefixed and suffixed by any number of packages:

    Konsist
        .scopeFromProject()
        .interfaces()
        .assertTrue { it.resideInPackages("..logger..") }

// logger - valid  
// com.logger - valid  
// com.logger.tree - valid
// com - invalid

By default, JUnit tests are run sequentially in a single thread. To speed up tests parallel execution can be enabled.

Create junit-platform.properties a file containing:

junit.jupiter.execution.parallel.enabled=true
junit.jupiter.execution.parallel.mode.default=concurrent
junit.jupiter.execution.parallel.config.strategy=dynamic
junit.jupiter.execution.parallel.config.dynamic.factor=0.95

Place this file in the resources directory of the test source set e.g:

src/test/resource/junit-platform.properties

or

src/konsistTest/resource/junit-platform.properties

Read more in the official JUnit5 documentation.

Videos

1. Maintain consistency in your Kotlin Codebase with Konsist!

2. Harmonizing Kotlin codebase with Konsist (KotlinConf 2024)

5. (FR)

Articles

1. All Generic Return Types Contain X In Their Name

@Test
fun `all generic return types contain X in their name`() {
    Konsist
        .scopeFromProduction()
        .functions()
        .returnTypes
        .withGeneric()
        .assertTrue { it.hasNameContaining("X") }
}

2. Property Generic Type Does Not Contains Star Projection

3. All Generic Return Types Contain Kotlin Collection Type Argument

4. Function Parameter Has Generic Type Argument With Name Ending With Repository

For large projects with many classes to parse, the default JVM heap size might not suffice. If you encounter java.lang.OutOfMemoryError: Java heap space error consider increasing the maxHeapSize for the test source set:

tasks.withType<Test> {
    maxHeapSize = "1g"
}

tasks.withType(Test).configureEach { 
    maxHeapSize = "1g" 
}

The source declaration (sourceDeclaration property) holds the reference to actual type declaration such as class or interface.

Konsist API allows for verify properties of such type e.g.:

• Check if property type implements certain interface

• Check if function return type name ends with Repository

• Check if parent class is annotated with given annotation

Every declaration that is using another type such as property, function, parent exposes sourceDeclaration property.

Let's look at few examples:

Verify Property Source Declaration

Check if type of current property is has a type which is a class declaration heaving internal modifier:

Verify Function Return Type Source Declaration

Check if function return type is a basic Kotlin type:

Verify Class Has Interface Source Declaration

Konsist can be used to guard the consistency of classes related to the [Kotlin Serialization](https://kotlinlang. org/docs/serialization.html) library.

1. Classes Annotated With Serializable Have All Properties Annotated With SerialName

@Test
fun `classes annotated with 'Serializable' have all properties annotated with 'SerialName'`() {
    Konsist
        .scopeFromProject()
        .classes()
        .withAnnotationOf(Serializable::class)
        .properties()
        .assertTrue {
            it.hasAnnotationOf(SerialName::class)
        }
}

2. Enum Classes Annotated With Serializable Have All Enum Constants Annotated With SerialName

3. All Models Are Serializable

The indirectParents parameter (parents(), hasParentClass(), hasAllParentInterfacesOf methods etc.). specifies whether or not to retrieve parent of the parent (indirect parents). By default, indirectParents is false e.g.

For above inheritance hierarchy is possible to retrieve:

1. Direct parents of ClassC (ClassB):

1. All parents present in the codebase hierarchy (ClassB and ClassC):

Notice that only parents existing in the project code base are returned.

Some code constructs can be represented as declarations (declaration-site) and as properties (use-site).

Declaration Site

Consider this annotation class:

The above code represents the declaration of the CustomLogger annotation class, the place in the code where this annotation is declared (declaration-site). This declaration can be retrieved by filtering KoScope declarations...

Konsist has first-class support for meaning that every following release will be developed with Kotest compatibility in mind. API has been improved to support Kotest flows. However, Konsist cannot automatically retrieve Kotest test names, meaning the test name won't appear in error logs upon test failure. To fully utilize Konsist with Kotest, you must explicitly provide the test name.

Setting The Test Name

Konsist can't obtain the test name from all dynamic tests (including tests).

It's recommended to provide the test name using the testName parameter. Supplying a test name provides additional benefits:

The declaration (KoDeclaration) represents a code entity, a piece of Kotlin code. Every parsed Kotlin File (KoFileDeclaration) contains one or more declarations. The declaration can be a package (KoPackageDeclaration), property (KoPropertyDeclaration), annotation (KoAnnotationDeclaration), class (KoClassDeclaration), etc.

Consider this Kotlin code snippet file:

The above snippet is represented by the KoFileDeclarationclass. It contains two declarations - property declaration (KoPropertyDeclaration

Snippets to library authors.

1. Every Api Declaration Has KDoc

2. Every Function With Parameters Has A Param Tags

1. Every Class Has Test

2. Every Class - Except Data And Value Class - Has Test

Sample tests writen using library.

1. Use Case Test

2. Use Case Tests

Snippets used to guard application architecture.

1. 2 Layer Architecture Has Correct Dependencies

2. Every File In Module Reside In Module Specific Package

When running using non- the default command line output contains only the test name:

To be able to see full exception log containing invalid declaration file path and line number enable exceptionFormat in Gradle testLogging:

Now log output provides all informations relevant to pin point the invalid declaration:

The full change log is available in the .

We appreciate your interest in Konsist. If you find our project valuable, please consider supporting Konsist through . Every contribution, no matter how small, adds up to make a significant impact.

Personal Support

Your personal sponsorship helps us continue our work and improve the tool for the entire community.

Retrofitting Konsist into a project that hasn't followed strict structural guidelines can pose initial challenges, necessitating a thoughtful approach to smoothly transition without disrupting ongoing development. Unlike most linters, which provide a baseline file, Konsist follows a different methodology (for now).

There are two approaches that can be employed when retrofitting Konsist into an existing projectAdd Konsist Existing To Project (Baseline) and Suppress Annotation.

Create Granular Scopes

Scope represents a set of Kotlin files. The scope allows to verification of all Kotlin files in the project or only a subset of the project code base.

When refactoring an existing application, you can either choose to first refactor a module and then add a Konsist test or initially add the Konsist test to identify errors, followed by the necessary refactor. Both strategies aim to ensure modules align with Konsist's structural guidelines.

Consider this The MyDiet application with feature 3 modules:

At first, the Konsist test can be applied to a single module:

As refactoring proceeds and code gets aligned, the Konsist scope can be extended to another feature module (featureGroceryListGenerator):

When entire code base (all modules) are aligned with the Konsist tests, the scope can be retrieved from the entire project:

Usage of project scope (scopeFromProject ) is a recommended approach because it helps to guard future modules without modifying the existing Konsist test.

Konsist provides a flexible API to create scopes from modules, source sets, packages, files, etc., and combine these scopes together. See .

Suppress Annotation

The second approach, Suppress Annotation, may be helpful when to Konsist swiftly without making substantial alterations to the existing kotlin files. See .

The primary focus of Konsist API is to reflect the state of the Kotlin source code (that will be verified), not the state of the running program. The Kotlin compiler has a deeper understanding of the Kotlin code base than Konsist, because the compiler can infer more information. Let's take a look at a few examples.

Class Example

Consider this class:

Is Logger class public? Yes obviously it is public, however, the hasPublicModifier method returns the false value:

Why is that? The public visibility modifier is the default visibility modifier in Kotlin. Meaning that class will be public even if it does not have the explicit public modifier. Since the class has no public modifier the hasPublicModifier method returns false. To distinguish between class being public and class having explicitpublic modifier Konsist API provides another method to retrieve declaration visibility:

Property Example

Let's look at the name property:

The name property is obviously of the String type. However String type is inferred, so Konsist has no way of Knowing the actual type (in this exact case this is achievable, but with more complex expressions containing delegates, setters, getters, or methods this approach would not work).

Primary Constructor Example

Let's look at the primary constructor for the same class:

The Logger the class has a primary constructor because the Kotlin compiler will generate a parameterless constructor under the hood. However, the Konsist API will return a null value because the primary constructor is not present in the Kotlin source code:

Function Return Type Example

Consider this function:

Kotlin will infer String as the return type of the getName function. Since the source code does not contain this explicit return type Konsist lacks information about the return type. In this scenario, hasReturnType the method will return the false value:

Unlike the previous example, Konsist has no way to determine the actual function return type.

Konsist occasionally releases snapshot versions to a dedicated snapshot repository. These snapshots provide early access to new features and bug fixes.

Snapshot Release Process

Currently, snapshots are released manually. At some point this process will be automated - new snapshot will be released each time code is merged to develop branch

How to Use Snapshots

Add Snapshot Repository

First, you need to include the snapshot repository in your project configuration. Here's how to do it for different build systems:

Add Konsist Dependency

To use Konsist SNAPSHOT dependency changing version to X.Y.Z-SNAPSHOT (versions can be found in ):

Code snippets employed to ensure the uniformity of tests written with JUnit library.

1. Classes With Test Annotation Should Have Test Suffix

@Test
fun `classes with 'Test' Annotation should have 'Test' suffix`() {
    Konsist
        .scopeFromSourceSet("test")
        .classes()
        .filter {
            it.functions().any { func -> func.hasAnnotationOf(Test::class) }
        }
        .assertTrue { it.hasNameEndingWith("Tests") }
}

2. Test Classes Should Have Test Subject Named Sut

3. Test Classes Should Have All Members Private Besides Tests

4. No Class Should Use JUnit4 Test Annotation

The annotation serves as a powerful tool to control lines and static analysis tools. When writing the Konsist test, there might be instances where the specific guard is not applicable due to certain project-specific reasons. The @Suppress annotation can be used to ignore those particular issues, ensuring that the codebase still adheres to the overall linting standards

In Konsist the @Suppress annotation parameter name is derived from the name of the test to be suppressed. For example - this test verifies if every API declaration has KDoc:

The name of the test is every api declaration has KDoc, so we can suppress this test by using one of these arguments:

Konsist enables development teams to enforce structural rules for interfaces ensuring code consistency across projects.

To verify interfaces start by querying all interface present in the project:

Konsist allows you to verify multiple aspects of a interfaces. For a complete understanding of the available APIs, refer to the language reference documentation for .

Let's look at few examples.

Functions can be validated for their signatures, modifiers, naming patterns, return types, and parameter structures.

To verify functions start by querying all functions present in the project:

In practical scenarios you'll typically want to verify a specific subset of functions - such as those defined inside classes:

Konsist API allows to query local functions:

Konsist allows you to verify multiple aspects of a functions. For a complete understanding of the available APIs, refer to the language reference documentation for .

Let's look at few examples.

Konsist can be used to guard the consistency of the project.

1. Classes Extending ViewModel

Properties can be checked for proper access modifiers, type declarations, and initialization patterns.

To verify properties start by querying all properties present in the project:

In practical scenarios you'll typically want to verify a specific subset of properties - such as those defined inside classes:

Konsist allows you to verify multiple aspects of a properties. For a complete understanding of the available APIs, refer to the language reference documentation for KoPropertyDeclaration.

Let's look at few examples.

The Konsist linter has undergone extensive field testing across a variety of projects, including , , and , and is compatible with both and build systems. Additionally, Konsist features a comprehensive test suite with around 5,000 tests, running on various operating systems including MacOS, Windows, and Ubuntu, to minimize the risk of regressions.

Konsist is safe for use because it is not bundled with the production code (only included in the test source sets).

Konsist Roadmap

Over the next few months, we will fix bugs, improve existing APIs, and implement missing features (in this order). Here is a high-level roadmap:

Many linters including and have a predefined set of rules. These rules are derived and aligned with guidelines or common practices for writing high-quality code and industry coding conventions (, , etc.).

However, there are no industry standards when comes to application architecture. Every code base is different - different class names, different package structures, different application layers, etc. As the project grows code base evolves as well - it tends to have more layers, more modules, and a more complex code structure. These "rules" are hard to capture by generic linter, because they are often specific to the given project.

Let's consider a use case - a concept defined by the . At a high level the use case definition is quite simple - "use case holds a business logic". How the use case is represented in the code base? Well... In one project this may be a class that has a name ending with UseCase, in another, it may be a class extending BaseUseCase and in another class annotated with @UseCase annotation. The logic for filtering "all project use cases" will vary from project to project.

Assertions are used to perform code base verification. This is the final step of Konsist verification preceded by scope creation (Create The Scope) and Declaration Filtering steps:

Assertion Methods

Konsist offers a variety of assertion methods. These can be applied to a list of KoDeclarations as well as a single declaration.

Assert True

In the below snippet, the assertion (performed on the list of interfaces) verifies if every interface has a public visibility modifier.

The it parameter inside the assertTrue method represents a single declaration (single interface in this case). However, the assertion itself will be performed on every available interface. The last line in the assertTrue block will be evaluated as true or false providing the result for a given asset.

Assert False

The assertFalse is a negation of the assertTrue method. In the below snippet, the assertion (performed on the list of properties) verifies if none of the properties has the Inject annotation:

This assertion verifies that the class does not contain any properties with public (an explicit public modifier) or default (implicit public modifier) modifiers:

Assert Empty

This assertion helps to verify if the given list of declarations is empty.

Assert Not Empty

This assertion helps to verify if the given list of declarations is not empty.

Assertion Parameters

Test Name

Assertions offer a set of parameters allowing to tweak the assertion behavior. You can adjust several settings, such as setting testName that helps with suppression (see ).

Strict

You can also enable enhanced verification by setting strict argument to true:

Additional Message

The additionalMessage param allows to provision of additional messages that will be displayed with the failing test. This may be a more detailed description of the problem or a hint on how to fix the issue.

Konsist enables development teams to enforce structural rules for class ensuring code consistency across projects.

To verify classes start by querying all classes present in the project:

Konsist allows you to verify multiple aspects of a class. For a complete understanding of the available APIs, refer to the language reference documentation for KoClassDeclaration.

Let's look at few examples.

Verify Name

Class names can be validated to ensure they follow project naming conventions and patterns.

Check if class name ends with Repository:

Verify Modifiers

Class modifiers can be validated to ensure proper encapsulation and access control.

Check if class has internal modifier:

Verify Annotations

Class-level and member annotations can be verified for presence, correct usage, and required attribute values.

Check if class is annotated with Service annotation:

Verify Package

Package declarations can be validated to ensure classes are located in the correct package structure according to architectural guidelines.

Check if class has model package or sub-packages (.. means include sub-packages):

Verify Methods

Methods can be validated for their signatures, modifiers, annotations, naming patterns, return types, and parameter structures.

Check if methods (functions defined inside class) have no annotations:

See .

Verify Properties

Properties can be checked for proper access modifiers, type declarations, and initialization patterns.

Check if all properties (defined inside class) has val modifiers:

See .

Verify Constructors

Primary and secondary constructors can be validated for parameter count, types, and proper initialization.

Check if class has explicit primary constructor:

Check if primary constructor is annotated with Inject annotation:

Verify Generic Type Parameters

Generic type parameters and constraints can be checked for correct usage and bounds declarations.

Check if class has not type parameters:

Verify Generic Type Arguments

Generic type arguments can be checked for correct usage.

Check if parent has no type arguments:

Verify Parents

Inheritance hierarchies, interfaces implementations, and superclass relationships can be validated.

Check if class extends CrudRepository:

Verify Companion Objects

Companion object declarations, their contents, and usage patterns can be verified for compliance.

Check if class has companion object:

Verify Members Order

The sequential arrangement of class members can be enforced according to defined organizational rules.

Check if class properties are defined before functions:

Type parameter vs type argument

To undersigned Konsist API let's look at the difference between generic type parameters and generic type arguments:

1. Type Parameter is the placeholder (like T) you write when creating a class or function (declaration site)

2. Type Argument is the actual type (like String or Int) you provide when using that class or function (use site)

Simple Examples:

Verify Type Parameters

Type parameters can be defined, for example, inside class or function.

Check whether a class's generic type parameter has the name UiState:

Check whether function type parameters has out modifier:

Verify Type Arguments

Check whether a property generic type argument has the name Service:

The flatten() extension method allows to flatten type parameters structure:

• For a type argument like String, it returns listOf().

• For a type argument like List<String>, it returns listOf(String).

• For a type argument like Map<List<String>, Int>, it returns

Check if all functions parameters are have generic type argument ending with UIState:

Check all parents have `String` type argument:

Konsist provides preconfigured sample projects. Each project contains a complete build script config and a simple Konsist test. Projects are available in the starter-projects directory. Each JUnit5 and Kotest project has an additional dynamic test (Dynamic Konsist Tests)(dynamic tests are currently available at the develop branch).

Projects:

Android

• JUnit 4

• JUnit 5

Spring

• JUnit 5

KMP

• JUnit5

• Kotest

To gain insight into the inner workings of the Konsist test, examine the data provided by the Konsist API.

Two primary tools can help you comprehend the inner workings of the Konsist API are Debug Konsist Test and Print To Console.

Evaluate Expression Debugger Window

The IntelliJ IDEA / Android Studio provides a handy feature called Evaluate Expressions which is an excellent tool for debugging Konsist tests.

Create a simple test class and click on the line number to add the :

Debug the test:

When the program stops at the breakpoint (blue line background) run Evaluate Expression... action...

...or press Evaluate Expression... button:

In the Evaluate window enter the code and click the Evaluate the button. For example, you can list all of the classes present in the scope to get the class names:

You can also display a single-class declaration to view its name:

Print To Console

Konsist provides a flexible API that allows to output of the specified data as console logs. Scopes, lists of declarations, and single declarations can all be printed.

Print a list of files from KoScope:

Print multiple declarations:

Print a given attribute for each declaration:

Print single declaration:

Print list of queried declarations before and after query:

Print nested declarations:

Konsist

The Konsist project is licensed under Apache License-2.0.

Dependencies

Third-party libraries, plugins, and tools that Konsist project uses:

See file for more details.

Konsist's Architectural Checks serve as a robust tool for maintaining layer isolation, enabling development teams to enforce strict boundaries between different architectural layers. Here few things that can be verified with Konsist:

• domain layer is independant

• data layer depends on domain layer

Snippets used to guard clean architecture dependencies.

1. Clean Architecture Layers Have Correct Dependencies

Konsist Declaration Checks provide a powerful mechanism for validating the structural elements of the Kotlin codebase. These checks allow developers to enforce structural rules and coding conventions by verifying classes, interfaces, functions, properties, and other code declarations. Here few things that can be verified with Konsist:

• All Use cases should reside in usecase specific package

• Repository classes must implement Repository interface

• All repository classes should have name ending with Repository

• data classes should have only val properties

• Test classes should have test subject named sut

• ...

Write First Declaration Check

Let's write a simple test to verify that all classes (all class declarations) residing in resides in controller package are annotated with the RestController annotation .

Overview

On a high level writing Konsist declaration check requires 4 steps:

Let's take a closer look at each of these steps.

1. Create The Scope

The first step is to get a list of Kotlin files to be verified.

The Konsist object is an entry point to the Konsist library.

The scopeFromX methods obtains the instance of the scope containing Kotlin project files. To get all Kotlin project files present in the project use the scopeFromProject method:

2. Retrieve Declarations

Each file in the scope contains set of declarations like classes, properties functions etc. (see ). To write this declaration check for all classes present in the scope query classes using classes method :

3. Filter Declarations

In this project controllers are defined as classes annotated with RestController annotation. Use withAllAnnotationsOf method to filter classes with with RestController annotation:

4. Define Assertion

To performa assertion use the assertTrue method:

To verify that classes are located in the controller package, use the resideInPackage method inside assertTrue block:

This verification applies to the entire collection of previously filtered classes, rather than examining just one class in isolation.

Wrap Konsist Code In Test

The declaration validation logic should be protected through automated testing. By wrapping Konsist checks within standard testing frameworks such as or , you can verify these rules with each :

Note that test class has a KonsistTest suffix. This is the recommended approach to name classes containing Konsist tests.

Summary

This section described the basic way of writing Konsist declaration test. To get a better understanding of how Konsist API works see and sections.

The above test will execute multiple assertions per test (all controllers will be verified in a single test). If you prefer better isolation each assertion can be executed as a separate test. See the page.

For dynamic tests, Konsist can't obtain the current test's name. Test name may be correctly displayed in the IDE, however, the testName argument should be provided to enable:

• Correct test names are displayed in the log when the test is failing

• Test suppression (See Suppress Konsist Test)

The testName argument should be passed to assertX methods such as assertTrue , assertFalse etc. Let's look at the code:

Here is the summary of test frameworks:

Here is a concrete implementation passing he testName argument for each test Framework:

Architecture assertions are used to perform architecture verification. It is the final step of Konsist verification preceded by scope creation (Create The Scope):

Assert Architecture

As an example, this simple 2-layer architecture will be used:

The assertArchitecture block defines architecture layer rules and verifies that the layer requirements are met.

Define Layers

Create class instance to represent project layers. Each Layer instance accepts the name (used for presenting architecture violation errors) and package used to define architectural layer:

Define Architecture Assertions

The final step is to define the dependencies (relations) between each layer using one of these methods:

• dependsOn

• dependsOnNothing

• doesNotDependOn

The above methods follow up the layer definitions inside assertArchitecture block:

Strict DependsOn

By default dependsOn method works like does not perform strict layer validation (strict = false). However this behaviour is controlled b ystrict parameter:

• strict = false (default) - may depend on layer

• strict = true - have to depend on layer

e.g.

Excluding Files

Architecture verification can be performed on KoScope (as seen above) and a list containing KoFiles. For example, you can remove a few files from the scope before performing an architectural check:

This approach provides more flexibility when working with complex projects, however, The desired approach is to create a dedicated scope. See .

Include Layer Without Defining Dependency

The method allows to include layer in architecture verification, without defining a dependency for this layer:

Architecture As A Variable

Architecture configuration can be defined beforehand and stored in a variable to facilitate checks for multiple scopes:

This approach may be helpful when refactoring existing applications. To facilitate readability the above checks should be expressed as two unit tests: