Mobile Unit Testing
Purpose
Plan unit tests for mobile logic: Jest (or Vitest where supported) covering pure functions, hooks, reducers, validation, and utilities — testing behavior, not internals.
When to Use
- When implementing logic worth verifying in isolation.
- Not for full user flows (
mobile-maestro-e2e) or rendered components (mobile-component-testing).
Inputs
- The logic under test and its behavior contract.
- Approved test runner (Jest/Vitest).
Discovery Questions
- Which logic is pure/isolatable (functions, hooks, reducers, validation)?
- What behaviors/edge cases must be covered?
- Which runner does the stack use (Jest typically for RN)?
Responsibilities
- Plan unit tests for pure functions, hooks, reducers, validation, utilities.
- Cover behavior and edge cases, not implementation detail.
- Align with the approved runner (Jest/Vitest).
- Coordinate broader coverage with
../../testing-strategy.
Required Workflow
- Identify isolatable logic.
- Define behaviors/edge cases to cover.
- Write unit tests with the chosen runner.
- Run + record results (or flag unrun).
- Record the unit-test plan.
Decision Rules
- Test behavior and contracts, not churn-prone internals.
- Jest is the common RN runner; use Vitest only where the stack supports it.
- Prioritize logic with real branching/edge cases.
- A bug-fix's regression test starts here where the logic is unit-level.
Rules
- Align with the approved runner.
- Test behavior, not implementation.
- Run tests or flag 'unverified until run'.
Anti-Patterns
- Testing implementation detail that will churn.
- Introducing a second runner without cause.
- Skipping edge cases.
- Claiming coverage from unrun tests.
Validation Checklist
Definition of Done
A recorded unit-test plan and tests: behavior-focused coverage of isolatable logic on the approved runner, run or explicitly flagged unrun — aligned with ../../testing-strategy.
Related Skills
../../testing-strategy, mobile-component-testing, mobile-maestro-e2e, mobile-validation, mobile-state-management
Related Knowledge
../../../knowledge/ (behavior contracts).
Related References
../../../references/mobile/state/ when populated.
Context Loading Guidance
- Requires: the logic under test + behavior contract, the runner.
- Does not require: unrelated modules, the full mobile skill set, unrelated references.
- May load:
../../testing-strategy for the overall plan.
- Stop when: unit tests are written and run (or flagged).
Token Efficiency Guidance
Focus on the logic in scope; don't load the whole app to unit-test a function.
1---2name: mobile-unit-testing3description: Use to plan unit tests for mobile logic — Jest (or Vitest where supported) for pure functions, hooks, reducers, and utilities. Test behavior, not implementation; align with the approved stack.4---56# Mobile Unit Testing78## Purpose910Plan unit tests for mobile logic: Jest (or Vitest where supported) covering pure functions, hooks, reducers, validation, and utilities — testing behavior, not internals.1112## When to Use1314- When implementing logic worth verifying in isolation.15- Not for full user flows (`mobile-maestro-e2e`) or rendered components (`mobile-component-testing`).1617## Inputs1819- The logic under test and its behavior contract.20- Approved test runner (Jest/Vitest).2122## Discovery Questions2324- Which logic is pure/isolatable (functions, hooks, reducers, validation)?25- What behaviors/edge cases must be covered?26- Which runner does the stack use (Jest typically for RN)?2728## Responsibilities2930- Plan **unit tests** for pure functions, hooks, reducers, validation, utilities.31- Cover **behavior and edge cases**, not implementation detail.32- Align with the **approved runner** (Jest/Vitest).33- Coordinate broader coverage with `../../testing-strategy`.3435## Required Workflow36371. Identify isolatable logic.382. Define behaviors/edge cases to cover.393. Write unit tests with the chosen runner.404. Run + record results (or flag unrun).415. Record the unit-test plan.4243## Decision Rules4445- Test behavior and contracts, not churn-prone internals.46- Jest is the common RN runner; use Vitest only where the stack supports it.47- Prioritize logic with real branching/edge cases.48- A bug-fix's regression test starts here where the logic is unit-level.4950## Rules5152- Align with the approved runner.53- Test behavior, not implementation.54- Run tests or flag 'unverified until run'.5556## Anti-Patterns5758- Testing implementation detail that will churn.59- Introducing a second runner without cause.60- Skipping edge cases.61- Claiming coverage from unrun tests.6263## Validation Checklist6465- [ ] Isolatable logic identified.66- [ ] Behaviors/edge cases covered.67- [ ] Approved runner used.68- [ ] Tests run (or flagged).69- [ ] Coordinated with testing-strategy.7071## Definition of Done7273A recorded unit-test plan and tests: behavior-focused coverage of isolatable logic on the approved runner, run or explicitly flagged unrun — aligned with `../../testing-strategy`.7475## Related Skills7677`../../testing-strategy`, `mobile-component-testing`, `mobile-maestro-e2e`, `mobile-validation`, `mobile-state-management`7879## Related Knowledge8081`../../../knowledge/` (behavior contracts).8283## Related References8485`../../../references/mobile/state/` when populated.8687## Context Loading Guidance8889- **Requires:** the logic under test + behavior contract, the runner.90- **Does not require:** unrelated modules, the full mobile skill set, unrelated references.91- **May load:** `../../testing-strategy` for the overall plan.92- **Stop when:** unit tests are written and run (or flagged).9394## Token Efficiency Guidance9596Focus on the logic in scope; don't load the whole app to unit-test a function.
ahtishamshahzad