Testing with real dependencies, and load numbers you can defend.

A test suite that mocks every dependency tells you your mocks work. Mocks encode your assumptions about how Postgres or Kafka behaves, and the bugs that reach production are usually the ones where that assumption was wrong — transaction semantics, serialization, ordering, timeouts. Testcontainers runs integration tests against the real thing in CI, so those assumptions get checked rather than restated.

No. Coverage is a proxy that stops being useful when it becomes the target — you get tests written to touch lines rather than to catch failures. We design the test pyramid around your actual risk areas: the paths where a defect is expensive, the integrations you do not control, the logic that changes often. Some code genuinely does not need a test, and pretending otherwise costs you the time that should have gone to the code that does.

Both, depending on the shape of the work. k6 fits teams who want load scripts in version control alongside the code and running in CI. JMeter is well-established, has broad protocol support, and is often already in the estate. Either way the important part is the scenario: load tests modelled on your actual traffic patterns tell you something, generic ramp tests mostly tell you the tool works.

By treating a flaky test as a defect in the test rather than an inconvenience to be retried around. A pipeline that fails on a real regression is only valuable if people believe it — once teams start re-running red builds by reflex, the signal is gone. Deterministic setup through Testcontainers removes a large share of the usual flakiness, which is shared external state.

It is a recorded measurement of latency and throughput under a realistic scenario, taken before the change. Without one, you cannot distinguish a regression from normal variance, and performance problems get discovered by users rather than caught in CI. With one, a change that degrades throughput fails the build with a number attached.