simba-testinglisted

Guide for testing Simba distributed lock and leader-election code. Use when writing or reviewing tests for MutexContender, SimbaLocker, AbstractScheduler, backend TCK conformance via MutexContendServiceSpec, Redis/JDBC/Zookeeper integration tests, timing-sensitive lock behavior, or new Kotlin assertions in Simba-based code.
Ahoo-Wang/skills · ★ 3 · Testing & QA · score 76

Install: claude install-skill Ahoo-Wang/skills

# Testing Simba-Based Code ## Test Strategy Overview Simba testing has three layers: 1. **Unit tests** — mock the `MutexContendServiceFactory`, test your business logic in isolation 2. **TCK (Technology Compatibility Kit)** — extend `MutexContendServiceSpec` to verify a backend implementation 3. **Integration tests** — run against a real backend (Redis, MySQL, Zookeeper) Choose the simplest layer that gives confidence. Most application code only needs unit tests with mocks. Backend implementors need TCK + integration tests. Before writing a test, decide: - **Application behavior**: mock `MutexContendServiceFactory`, capture the contender, and pass ownership changes to `notifyOwner`. - **Backend implementation**: extend `MutexContendServiceSpec` and run against the real backend. - **Scheduler behavior**: verify leadership gating separately from the business logic in `work()`. ## Unit Tests with MockK For application code that injects `MutexContendServiceFactory`, call the component under test and mock only the factory seam: ```kotlin import io.mockk.every import io.mockk.mockk import io.mockk.verify import me.ahoo.simba.core.MutexContendService import me.ahoo.simba.core.MutexContendServiceFactory import me.ahoo.simba.core.MutexContender import me.ahoo.simba.core.MutexOwner import me.ahoo.simba.core.MutexState class MyComponentTest { private val mockFactory = mockk<MutexContendServiceFactory>() private val mockService = mockk<MutexContendService>(relaxed = true)