Konsist Documentation

This starter project demonstrates how to integrate Konsist into a Kotlin Multiplatform (KMP) environment using Gradle and JUnit 5. The sample includes two types of test implementations located in the konsistTest module:

• Single test approach: SampleKonsistTest.kt contains a single test for each Konsist check.
• Dynamic test approach: SampleDynamicKonsistTest.kt uses dynamic tests to cover multiple checks.

Project structure for tests:

• konsistTest/src/jvmTest/kotlin/com/sample/SampleKonsistTest.kt
• konsistTest/src/jvmTest/kotlin/com/sample/SampleDynamicKonsistTest.kt

The konsist-path-tester project is a specialized test suite used to verify the correctness of Kotlin file querying logic within Konsist. It specifically validates:

• test scope creation: How scopes are defined and initialized.
• test scope operators: The behavior of operators used within scopes.
• test hasTest logic: The accuracy of the hasTest property/logic during querying.

This sample demonstrates how to integrate Konsist into a project using Maven, Spring, and JUnit 5.

Key structural details:

• Test Location: Konsist tests reside in the konsistTest module.
• Test Types:
  • SampleKonsistTest.kt: Contains a single test for each Konsist check.
  • SampleDynamicKonsistTest.kt: Contains multiple tests for each Konsist check.
• Source Set: The konsistTest source set is defined using the JVM Test Suite Plugin.

This starter project demonstrates how to integrate Konsist into an Android environment using Gradle Kotlin DSL and JUnit 5.

Key files in this sample include:

• konsistTest/src/test/kotlin/com/sample/SampleKonsistTest.kt: Demonstrates single tests for each Konsist check.
• konsistTest/src/test/kotlin/com/sample/SampleDynamicKonsistTest.kt: Demonstrates multiple tests for each Konsist check.

The konsist-declaration-tester project is a specialized test suite designed to verify the correctness of Kotlin file querying logic within Konsist. It specifically validates the following internal mechanisms:

• hasTest logic: Verifying how Konsist identifies test files.
• module and sourceSet logic: Ensuring correct resolution of modules and source sets.
• KoChildDeclaration: Testing the handling of child declarations within the Kotlin structure.

The circulardependency1 scenario demonstrates a test case where three layers form a closed loop of dependencies. In this pattern, Layer1 depends on Layer2, Layer2 depends on Layer3, and Layer3 depends back on Layer1. This is used to test the ability of Konsist to detect architectural violations where circularity is introduced across multiple layers.

%%{init: {'theme': 'forest'}}%%
flowchart LR
    Layer1 --> Layer2
    Layer2 --> Layer3
    Layer3 --> Layer1

The 'Circular dependency 3' scenario demonstrates a complex circular dependency pattern across multiple layers. In this model, dependencies flow as follows:

1. Layer1 depends on Layer2.
2. Layer2 depends on Layer3.
3. Layer3 depends on both Layer1 (completing the cycle) and Layer4.

This scenario is used to test how Konsist detects multi-step circular dependencies that traverse through intermediate layers.

%%{init: {'theme': 'forest'}}%%
flowchart LR
    Layer1 --> Layer2 
    Layer2 --> Layer3
    Layer3 --> Layer1 & Layer4

The Circular dependency 2 scenario is a test case designed to demonstrate how Konsist detects complex circular dependencies across multiple layers. In this specific scenario, the dependency flow is structured as follows:

• Layer 1 depends on Layer 2 and Layer 3.
• Layer 2 depends on Layer 4 and Layer 5.
• Layer 3 depends on Layer 5.
• Layer 4 creates a circular dependency by depending back on Layer 1.

This creates a cycle: Layer 1 -> Layer 2 -> Layer 4 -> Layer 1.

Architecture 7 defines a specific dependency hierarchy for layered architectures. When implementing this pattern using Konsist, ensure your layers follow these dependency constraints:

• The Adapter layer is allowed to depend on the Common and Port layers.
• The Port layer is allowed to depend on the Domain and Common layers.
• The Domain layer is allowed to depend on the Common layer.
• The Common layer must have no dependencies.

This structure is represented by the following dependency flow: Adapter $\rightarrow$ Port $\rightarrow$ Domain $\rightarrow$ Common (and Adapter $\rightarrow$ Common, Port $\rightarrow$ Common).