@mrciphersmith/keryx 0.3.3 → 0.3.5

package/src/gdskills/bundled/stacks/kotlin-android/skills/kotlin-android-testing/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: kotlin-android-testing
+description: "Use when a Kotlin/Android module's test suite needs writing, extending, or fixing -- runTest/TestDispatcher for suspend functions and ViewModels, ComposeTestRule semantics-based finders for UI tests, and MockK at the repository/data-source interface boundary."
+triggers:
+  - "write tests for this ViewModel"
+  - "add a Compose UI test for this screen"
+  - "fix this flaky Android test"
+  - "test this suspend function"
+  - "mock the repository for this unit test"
+  - "cover this feature module with tests"
+  - "the test for this screen keeps timing out"
+metadata:
+  origin: authored
+  category: test
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Kotlin/Android testing
+
+Write, extend, or fix a Kotlin/Android module's test suite: coroutine
+tests with `runTest`/`TestDispatcher`, Compose UI tests with
+`ComposeTestRule`, and interface-boundary mocking. `rules/testing.mdc`
+carries the full rule set this skill's checklist is built from — read it,
+not just this summary, before writing tests.
+
+## Workflow
+
+### Step 1: Discover the project's test conventions
+
+1. Read the module's `build.gradle(.kts)` test dependencies: MockK vs
+   Mockito, `kotlinx-coroutines-test` version, and whether a Compose UI
+   test dependency (`androidx.compose.ui:ui-test-junit4`) is present.
+2. Find the layout: unit tests under `src/test/`, instrumented/Compose UI
+   tests under `src/androidTest/`. Match whichever the module already
+   uses; do not invent a third location.
+3. Read 1-2 neighboring test files for: dispatcher-rule setup (a shared
+   `MainDispatcherRule` or manual `Dispatchers.setMain`/`resetMain`),
+   whether MockK or Mockito is standardized, and existing fixture/builder
+   helpers for constructing test data.
+
+### Step 2: Plan test cases
+
+**`ViewModel`/suspend functions:** happy path, error/exception path from
+a mocked dependency, and any intermediate state a caller can observe (a
+loading state before a result arrives) using a `StandardTestDispatcher`
+you advance explicitly.
+
+**Compose UI:** initial render state, a user interaction
+(`performClick()`, `performTextInput()`) and its resulting state/text
+change, and a conditionally-shown element's visibility.
+
+**Repository/data layer:** success and failure responses from the mocked
+network/database boundary, and that a domain-level error type is what
+actually reaches the caller (not a raw exception leaking through).
+
+### Step 3: Write
+
+1. Wrap coroutine test bodies in `runTest { }`; install a `TestDispatcher`
+   for `Dispatchers.Main` via a shared JUnit rule (or manual
+   `Dispatchers.setMain(...)`/`Dispatchers.resetMain()` in
+   `@Before`/`@After`) so `viewModelScope` resolves to it.
+2. Mock the `Repository`/`ApiService`/data-source interface the class
+   under test depends on with MockK (`mockk<Repo>()`,
+   `coEvery { repo.fetch() } returns result`) — never stub the class
+   under test's own internals.
+3. For a Compose UI test, use `createComposeRule()` (or
+   `createAndroidComposeRule<Activity>()` when an Activity host is
+   needed) and find nodes via `onNodeWithText`/
+   `onNodeWithContentDescription`/`onNodeWithTag`, not structural
+   indexing.
+4. Advance the test dispatcher deliberately
+   (`advanceUntilIdle()`/`runCurrent()`) at the point where the test
+   needs to observe an intermediate or final state — never a fixed
+   `delay`/`Thread.sleep` to "give it time."
+5. Assert both the rendered/returned state and, where relevant, a
+   `coVerify { repo.save(...) }` that the right interaction actually
+   happened.
+
+### Step 4: Run and fix
+
+```bash
+./gradlew testDebugUnitTest
+```
+
+Run `./gradlew connectedDebugAndroidTest` (or the project's Compose UI
+test task) for instrumented tests when relevant. Fix failing tests (max 3
+iterations) — fix the test, not the source under test, unless the test
+itself has correctly caught a real bug (say so in the report rather than
+silently changing production code).
+
+### Step 5: Report
+
+```
+Generated: feature/profile/ProfileViewModelTest.kt
+  - 6 cases (runTest + StandardTestDispatcher), repository mocked with MockK
+  - ./gradlew testDebugUnitTest passes
+```
+
+## Rules
+
+- ALWAYS match the project's existing dispatcher-rule and mocking-library
+  conventions found in Step 1, not a different project's style.
+- NEVER modify source code — only test files.
+- NEVER use `Thread.sleep`/a fixed `delay` to wait for a coroutine or
+  Compose UI update; use `runTest`'s virtual time, `advanceUntilIdle()`,
+  or `composeTestRule.waitUntil { ... }`.
+- Mock at the repository/data-source interface boundary, never the class
+  under test's own private methods or fields.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll add a short delay so the coroutine has time to finish" | Non-deterministic and slow; `runTest`'s virtual clock plus `advanceUntilIdle()` makes the wait both instant and deterministic |
+| "I'll just mock a private method on the ViewModel itself to control what it returns" | Testing a mocked-out internal instead of real behavior; mock the repository/data-source interface the ViewModel actually depends on |
+| "This UI test keeps flaking, I'll add a `Thread.sleep(500)` before the assertion" | Hides a real synchronization gap; use `composeTestRule.waitUntil { ... }` or advance the test dispatcher instead |
+| "I'll loosen this assertion to just check the call didn't throw" | Covers nothing about which state or value resulted; assert the actual state/text/interaction outcome |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- The test file sits at the project's own convention path
+  (`src/test/`/`src/androidTest/`), matching Step 1's findings.
+- `./gradlew testDebugUnitTest` (and the instrumented task, if touched)
+  exits 0 with every generated test passing.
+- `git status` shows only test files added or modified; no source file
+  under test changed.
+- No test synchronizes with `Thread.sleep`/a fixed `delay`.

package/src/gdskills/bundled/stacks/kotlin-android/skills/kotlin-android-testing/evals.json

@@ -0,0 +1,77 @@
+{
+  "triggers": {
+    "positive": [
+      "This ViewModel's loadProfile function needs test coverage before we merge",
+      "Add a test that clicking the retry button actually triggers a refetch",
+      "The repository call in this suspend function isn't covered by any test",
+      "Write a test for the error state shown when the network call fails",
+      "This screen's test keeps waiting forever, can you fix it",
+      "We need a test proving the save button disables itself while saving",
+      "Cover this list-filtering logic in the ViewModel with unit tests"
+    ],
+    "negative": [
+      "Write an XCTest for this SwiftUI view model's published property",
+      "Add a widget test for this Flutter StatefulWidget's local state",
+      "Write an xUnit test for this ASP.NET Core controller action",
+      "Add a React Testing Library test for this component's click handler",
+      "Write a pytest case for this FastAPI endpoint's validation logic",
+      "Review this Kotlin diff for exported manifest components before merge",
+      "Fix the failing Gradle build after this dependency version bump"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "mock-repository-boundary",
+      "prompt": "I have a ViewModel with a `loadProfile()` function that calls `profileRepository.fetch()`, a suspend function declared on a `ProfileRepository` interface. I want to unit test what happens when that call fails. How should I set up the mock?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer mocks the ProfileRepository interface itself (with MockK, unless the project already standardizes on Mockito), stubbing its suspend fetch() function with a coroutine-aware form (e.g. coEvery { repository.fetch() } throws SomeException()) to simulate the failure, rather than reaching into the ViewModel under test to stub its own internal method or field.",
+          "pass_criteria": [
+            "Mocks the ProfileRepository interface (the collaborator/dependency), not the ViewModel under test's own internals.",
+            "Uses a coroutine-aware stubbing form for the suspend fetch() call (e.g. coEvery ... throws / coEvery ... returns), not the plain non-suspend every/when form.",
+            "States that the ViewModel is then exercised through its real loadProfile() call with the mocked repository injected, and the resulting error state is asserted."
+          ],
+          "fail_criteria": [
+            "Recommends stubbing or overriding a private method or field on the ViewModel under test itself instead of mocking the ProfileRepository dependency.",
+            "Uses a plain, non-coroutine-aware mocking call (e.g. every { repository.fetch() } ...) on a suspend function without a coroutine-aware form."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Mock the `ProfileRepository` interface, not the ViewModel: `val repository = mockk<ProfileRepository>()`, then stub the failure with the coroutine-aware form since `fetch()` is a suspend function -- `coEvery { repository.fetch() } throws IOException()`. Construct the ViewModel with that mocked repository injected, call `viewModel.loadProfile()` inside `runTest { }`, advance the test dispatcher, and assert the ViewModel's exposed state ended up in its error variant. The mock stays at the repository boundary the whole way through; the ViewModel's own internals are exercised for real, which is what actually proves the error-handling path works.",
+        "known_wrong": "Since `loadProfile()` is public but calls a private `handleFetch()` helper internally, just use MockK's `spyk` on the ViewModel itself and stub `every { viewModel invoke \"handleFetch\" }` (or override the private method via reflection) to throw the exception directly -- that way you don't need to worry about setting up the repository interface at all, you're testing exactly the branch you care about.",
+        "vague": "Mock the dependency so the failure path runs and check that the ViewModel ends up in an error state.",
+        "subtle_wrong": "Mock the repository, but since `fetch()` is just a regular function call from the test's point of view, stub it the normal way: `every { repository.fetch() } throws IOException()`. It compiles and the test passes locally, so the coroutine-specific stubbing form isn't really necessary here."
+      }
+    },
+    {
+      "id": "suspend-function-runtest",
+      "prompt": "I want to test a suspend function in this repository class that calls `delay(2000)` before returning a cached value if the network is slow. What's the right way to test that without the test actually taking two seconds?",
+      "strictness": "high",
+      "expected_behavior": [
+        { "grader": "regex", "value": "runTest" },
+        {
+          "grader": "judge",
+          "rubric": "A correct answer wraps the test body in kotlinx-coroutines-test's runTest { }, which runs on a virtual clock that skips real delay time, so the suspend function's delay(2000) resolves instantly inside the test instead of the test actually pausing for two seconds; it does not rely on Thread.sleep or reducing the delay value in production code to make the test fast.",
+          "pass_criteria": [
+            "Names runTest { } as the mechanism that makes the test not actually wait for the delay.",
+            "Explains that runTest's virtual/skipped time is what avoids the real two-second wait, not a change to the delay duration itself.",
+            "Does not require changing the production delay(2000) call just to make the test faster."
+          ],
+          "fail_criteria": [
+            "Recommends using Thread.sleep, a shortened delay in a test-only build variant, or otherwise altering production code's delay value to make the test run fast.",
+            "Recommends running the suspend function with runBlocking and simply accepting the real two-second wait as unavoidable."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Wrap the test body in `runTest { }` from `kotlinx-coroutines-test`. It runs the coroutine on a `TestScope` with a virtual clock, so when the code under test hits `delay(2000)`, the test doesn't actually pause for two real seconds -- the virtual clock just advances past it and the suspend function resumes immediately. Call the repository function directly inside `runTest { }`, e.g. `val result = repository.fetchWithCache()`, and assert on `result` right after; there's no need to touch the production `delay(2000)` call or introduce a test-only flag to shorten it, since `runTest` already makes the wait free without changing the code under test at all.",
+        "known_wrong": "Just run it under `runBlocking { }` like normal and accept that the test takes two seconds -- it's not a huge deal, and it's simpler than learning `runTest`'s virtual-time behavior. If it's really a problem, add a `testMode` flag to the repository that skips the `delay` call entirely when running under test, and set that flag from the test setup.",
+        "vague": "Use a coroutine test utility that lets the delay resolve fast instead of actually waiting.",
+        "subtle_wrong": "Use `runTest { }` for the test body, but also pass a shortened `delayMillis = 50` parameter into the repository function's signature for testing, since that guarantees the test is fast regardless of how `runTest` happens to handle the delay internally -- belt and suspenders."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/swift-ios/agent-refs.json

@@ -0,0 +1,4 @@
+{
+  "agents": [],
+  "note": "no pair -- honest DeepSeek deepseek-chat runner+judge gate (trials=10, strictness=high, flow 336) fails all 4 skills on trigger accuracy, never on behavior (every behavior scenario 1.0/1.0): swiftui-implementation TP 1/7 FP 0/7, swift-testing TP 3/7 FP 0/7, swift-code-review TP 2/6 FP 2/7 (a Swift diff wrongly routed to review when the prompt asked to implement a fix, despite the skill's own 'Read-only, no edits' description clause), swift-build-fix TP 1/6 FP 0/7. Genuine routing weakness against a crowded catalog, not an authoring defect -- stays experimental per flow 336's stack-pack-lessons.md rule against tuning descriptions to restate failing eval prompts."
+}