Use compile-time DI checks without losing runtime tests

Compile-time dependency validation can catch a missing definition, an invalid qualifier, or a broken constructor path before an application starts. That is valuable. It does not prove that runtime configuration, parameters, or lifecycle behavior are correct.

Divide the evidence

Let compiler validation answer structural questions:

• Can the graph resolve this constructor path?
• Does a binding exist for the requested type and qualifier?
• Is generated wiring compatible with the declaration?

Let tests answer behavioral questions:

• Does the selected environment provide the expected base URL?
• Does a signed-in session receive a session-owned object?
• Can two parameterized feature instances remain isolated?
• Is a resource closed when its owner ends?

Koin now documents a compiler plugin for compile-time dependency validation and describes the older runtime verification APIs separately. Review the current verification documentation before removing a test. Remove a runtime graph test only when compiler validation covers the same structural case and another test covers the runtime behavior.

Keep failure messages local

Organize definitions by feature or capability so validation errors point to a small graph. Typed qualifiers and constructor injection also make the reported path easier to understand. If validation requires a long list of exceptions, dynamic values, and ignored types, the graph boundary may be too broad.

The aim is layered confidence: the compiler checks what can be known at build time, a focused verification test checks a runtime graph slice, and behavior tests check ownership and configuration. One layer should not be treated as proof of all three.