Overview
Testing ensures that our applications remain reliable, offline-first capabilities behave correctly, and changes do not break shared modules.🏛 Test Levels & Scope
We test our codebase across three distinct levels:| Level | Scope | Target Areas |
|---|---|---|
| Unit Tests | Pure logic, helper functions, and data mappers | Models, JSON parsing, result converters, and business logic |
| Widget Tests | Single screens, UI components, and state controllers | Brand wrappers, form validation, and screen transitions |
| Integration Tests | End-to-end user journeys and sync behavior | PowerSync data uploads, authentication cycles, and background tracking |
🧪 Key Testing Rules
1. High Coverage on Shared Packages
Because the shared packages (packages/core_*) are load-bearing for all applications, they require the strictest test coverage. A regression in a core package could break multiple apps simultaneously.
2. Integration Testing for PowerSync
Since data sync is critical, we write integration tests to verify:- Upload Queue Replay: Testing that local writes are correctly uploaded when the network comes back online.
- Sync Rules Bucket Correctness: Verifying that each user scenario replicates only the correct data partition to the device (ensuring user isolation).
- Permanent Rejections: Verifying that when a write is rejected by the Go backend (e.g., validation failure), the queue does not wedge and the error surfaces reactively in the
rejected_mutationstable.