Shipping With Confidence: TDD and Real-Database CI

Confidence to ship comes from tests you trust — bloc_test, a real Postgres in CI, and provable idempotency.

Confidence to ship comes from tests you trust. I lean on test-driven development for business logic and a CI pipeline that exercises the real moving parts, not mocks of everything.

For Flutter, bloc_test makes state machines a pleasure to verify: given an event, assert the exact sequence of states. Use cases and mappers are plain Dart, so they are fast unit tests. I keep a coverage ratchet so coverage can only go up, never silently down.

On the backend, I run tests against a real PostgreSQL in CI (via a throwaway container) rather than an in-memory fake. Migrations, constraints, and transaction behavior only show their true colors against the real engine — and that is exactly where production bugs hide.

Idempotency is non-negotiable for anything that retries or back-fills. I prove it with a test that runs the operation twice and asserts the same end state. Combined with shadow-comparison before a risky cutover, it turns scary migrations into routine ones.

None of this is about chasing 100% coverage. It is about covering the paths where a bug costs money or trust, and making the suite fast enough that you actually run it. Green build, ship.

Confidence to ship comes from tests you trust — bloc_test, a real Postgres in CI, and provable idempotency.

Confidence to ship comes from tests you trust. I lean on test-driven development for business logic and a CI pipeline that exercises the real moving parts, not mocks of everything.

None of this is about chasing 100% coverage. It is about covering the paths where a bug costs money or trust, and making the suite fast enough that you actually run it. Green build, ship.