What problem does it solve? Writing tests for the Husi project requires knowing its specific conventions: hand-rolled fakes instead of mockk, Koin-aware base classes, and StandardTestDispatcher wiring. Without this guidance, tests hang, pollute each other through DataStore globals, or fail at runtime with Koin resolution errors. ## Core Features & Use Cases - Base class selection: Choose between MainDispatcherTest, HusiKoinTest, HusiKoinMainDispatcherTest, and HusiHttpKoinTest based on whether the code touches Koin singletons or coroutine dispatchers. - Fake-based testing: Use FakeRepository, FakeHttpClientFactory, and related fakes instead of mockk, with recorder-style assertions on lastRequest and lastResponse. - Testability refactoring: Introduce DI seams (interface, Koin binding, constructor injection, fake) when production code calls statics like Libcore.newHttpClient(). - Use Case: When adding a test for a ViewModel that resolves Repository and uses viewModelScope, extend HusiKoinMainDispatcherTest, run with runTest(dispatcher.scheduler), and collect SharedFlow events via backgroundScope.async before triggering the emit. ## Quick Start Ask the assistant to write a unit test for a specific ViewModel or updater class under composeApp following the husi-testing conventions.