architecture_test_tools.md

architecture_test_tools.md

Tooling option	Strong at	Weak at	Use it when	Combine with Konture when
ArchUnit	Mature JVM bytecode rules and class dependency checks	Gradle project graph, KMP source sets, source-level Kotlin intent	The system is primarily JVM and the rule is visible in compiled classes	You also need module dependency policy, Kotlin visibility, or KMP/platform boundaries
detekt custom rules	Kotlin PSI, style, naming, local declaration rules	Gradle module graph and cross-module dependency policy	The rule is close to lint: naming, annotations, local source conventions	A lint finding needs to line up with module ownership or public API boundaries
Gradle Doctor or module-graph plugins	Build health, project graph visibility, dependency reports	Source imports, signatures, class visibility, API leakage	You need graph insight, build performance reports, or dependency hygiene	A graph edge is only half the story and source-level leakage also matters
Custom PSI tools	Highly specific Kotlin source rules	Maintenance cost, build integration, graph awareness	You have a narrow organization-specific rule and the team can own the tool	The custom rule should run next to build-graph contracts
Runtime or UI testing tools such as Kakao	User flows and Android UI behavior	Static architecture	You are validating behavior, screens, and interaction flows	Structural boundaries should fail before they become runtime behavior defects
Plain review checklists	Judgment, nuance, exceptions	Consistency under time pressure	The rule is still evolving or depends on human design trade-offs	The checklist item becomes stable enough to execute in CI

Kotlin Architecture Tests: What They Are and Why They Matter - Part 1/3
Kotlin Architecture Tests: Why Konture Exists - Part 2/3
Kotlin Architecture Tests with Konture: A Practical Guide - Part 3/3