mockk-testing-patterns

name: mockk-testing-patterns description: 'Repo-specific MockK testing workflow for AniTrend. Use when writing or reviewing unit tests or androidTest coverage with MockK, deciding between every/coEvery or verify/coVerify, checking Koin modules with mock providers, or confirming whether MockK dependencies need to be added manually. Covers buildSrc auto-wiring, coroutine-aware stubbing, and concrete AniTrend test examples.' argument-hint: '[what are you testing, for example: converter, mapper, use case, ViewModel, worker, or Koin module]'

You are adding or reviewing AniTrend tests that rely on MockK.
You need to decide whether a test belongs in test or androidTest.
You need the correct MockK primitive for a suspend call, regular function, or DI graph check.
You want examples that match AniTrend's buildSrc-managed test stack instead of adding ad hoc dependencies.

A test in the correct source set.
MockK usage aligned with AniTrend's existing JUnit, coroutine-test, Turbine, and Koin setup.
Minimal mocking at the boundary under test instead of mocking value objects or the class under test.
Verification steps that prove the test actually exercised the intended behavior.
Guidance for common AniTrend extensions: Flow or DataState assertions, worker logic coverage, and test review checks.

Start with src/test unless the code needs Android framework runtime behavior.
Do not add testImplementation or androidTestImplementation for MockK in normal modules. buildSrc already injects MockK, JUnit, Turbine, and coroutine-test.
Prefer real domain models, entities, and params when construction is cheap. Mock collaborators, not simple value objects.
Use every and verify for regular calls.
Use coEvery and coVerify for suspend calls.
Pair MockK with Turbine when validating Flow or DataState emissions.
Use Koin's MockProviderRule.create { mockk() } for DI graph tests when the test is in androidTest and validates the real module graph.
Finish with meaningful assertions or verification, then use confirmVerified when interaction coverage matters.

Place tests in src/test by default.
Move to androidTest only when the code under test directly invokes Room, ContentResolver, WorkManager scheduling, or another Android runtime dependency that requires a device or emulator to instantiate.

Identify the test shape. Use a pure unit test for converters, mappers, state holders, use cases, and most repository helpers. Use androidTest only when Android APIs, startup wiring, or integration behavior requires it.
Check the closest repo reference before inventing a pattern. Read project wiring and MockK API notes for where MockK is injected and how the repo currently stubs collaborators.
Choose the smallest useful mock surface. Mock interfaces, gateways, DAOs, helpers, or repositories. Keep data fixtures real unless the type is too expensive or awkward to construct.
Stub with the matching API. Use every { ... } returns ... for synchronous members. Use coEvery { ... } returns ... for suspending collaborators. Use just Runs for non-suspending functions that return Unit. Use just Awaits for suspending functions that return Unit. For all other return types, provide an explicit return value with returns.
Execute under the standard test runtime. Use runTest for suspend paths. Use Turbine for Flow assertions.
Verify the contract. Assert returned state first. Add verify or coVerify for collaborator interactions that define the behavior.
Run the narrowest relevant command. Prefer module-targeted tests while iterating, then run the wider debug unit suite before closing the work.

Use MockK to control upstream collaborators.
Use Turbine to assert emissions.
Assert every emission that a downstream collector would act on, typically Loading, Success, and Error. Skip internal buffering or operator-level intermediate values that are not part of the public contract.
If the stream is long-lived, end with cancelAndIgnoreRemainingEvents() or use expectMostRecentItem() when that matches the contract better.
Start with a unit test when the flow can be exercised without Android runtime. Use androidTest only when the source depends on Room, a ContentResolver, or another Android integration point.

Prefer testing the worker's core decision path directly instead of booting the full WorkManager runtime.
If a worker mixes parameter decoding, interactor invocation, and result mapping, extract the result-mapping logic behind a small seam and unit test that seam with MockK.
Reserve WorkManagerTestInitHelper for the smaller set of cases that truly require end-to-end scheduling or runtime behavior.
For AniTrend's current task modules, this is the recommended pattern because the repo has many coroutine workers but little value in heavy scheduling tests for each one.

Ask whether the test would still pass if the production behavior regressed in the way you care about.
Remove mocks for simple data carriers if a real instance is cheaper and clearer.
Replace broad any() matchers with concrete values when those values are part of the contract.
Verify only behavior that matters externally.
Check that the test name describes the scenario and the expected outcome.

Situation	Use
Regular function or property	`every` and `verify`
Suspend function	`coEvery` and `coVerify`
Fire-and-forget dependency call	`just Runs` with `verify`
`Flow` or `DataState` output	MockK plus Turbine
Koin module validation	`MockProviderRule.create { mockk() }`
Need partial real behavior	`spyk`, but only when a focused seam is not practical