How do I integrate test coverage reports into my IDE?

That's a really sharp point about the language server approach. It changes the mental model from "seeing coverage" to "reasoning with coverage," which is a big leap. The conflict you mentioned with other tools is so real, especially when you've got a TypeScript LSP, a debugger, and a test runner extension all trying to own the same symbols.

One thing I'd add to the configuration tax is the maintenance burden as dependencies upgrade. That finely-tuned `settings.json` can become a fragile house of cards after a VS Code or extension update. I've found it helps to document not just the settings, but the *order* in which extensions load, which sometimes makes all the difference.

Coverage Gutters is the one you'll want for VS Code, it's super reliable for painting that gutter right in your editor.

The CI question is the key. Chasing a live cloud report adds a ton of complexity. I've had good luck with the approach others mentioned, making my local Docker setup mirror CI exactly. If your Terraform defines the test runner there, you can just run it locally and get an identical lcov file every time. That way, your plugin isn't guessing or syncing, it's just reading the truth.

It keeps things simple, and you're already set up for it. What test runner are you using? Some frameworks make this local/CI consistency easier than others.

I agree that a mirrored local environment is the most reliable foundation, but the practical challenge is state synchronization. A containerized runner defined in Terraform solves for binary and library consistency, but if your tests interact with external services, databases, or cloud APIs, you now have to replicate that state locally as well. That's often the hidden cost that makes the "simple" container approach quite complex.

You can mitigate this by designing your integration tests to be hermetic, using test doubles for any external integration, but that's a significant architectural commitment. Without it, your local lcov file, while generated from an identical runner, might still represent a different execution path compared to CI.

What's your strategy for managing test data and external service state between these mirrored environments? That's usually the fracture point.

You're right to zero in on state as the fracture point. Even with hermetic tests, the data problem remains. For a PostgreSQL-backed service, we ended up using testcontainers with a predefined, minimal schema and dataset that gets loaded for both local and CI runs. The "runner" module in Terraform just defines the container spec, and both environments use it as a source of truth.

This still requires discipline. Any migration must be backwards-compatible for tests, and you're essentially maintaining a parallel, stripped-down schema. But it does align the execution path. The bigger tension I've seen is when teams adopt this pattern but then let "fast" unit tests run outside the container, defeating the whole consistency goal.

That tip about checking the test runner's docs first is a good one. I've seen people install the plugin and then get stuck because they don't know what flag to use.

When you say "master the local flow first," does that mean you think the sync from CI is often an unnecessary complication? I'm still trying to figure out when you'd really need to pull the CI artifact versus just trusting the local run.

I think focusing on the local flow is the right place to start. The plugin just reads a file, so if your local process creates the same file as CI, you're set.

I'm curious though, what stops you from trusting the local run? Is it because the CI environment has specific secrets or connections your local setup doesn't?

That's a really practical question about trust. In my experience with ERP systems, it's less about secrets and more about transactional state. A local test run might use an in-memory database, but the CI job could be hitting a real, isolated PostgreSQL instance. Even if the schema is the same, the query planner or locking behavior can diverge, leading to different code paths being exercised.

So the coverage file might be structurally identical, but it could represent a different set of logical branches being hit. That's the gap that makes me hesitant to trust local runs for anything beyond unit-level validation.

For integration-heavy tests, have you found a reliable way to standardize the state of those external dependencies, or do you accept some level of drift between local and CI coverage?

So you're maintaining a parallel schema just for tests? That's not a source of truth, it's a vendor lock-in recipe. What happens when you need to change a core DB feature and your test schema is now a legacy artifact?

You've identified a real risk. Treating a test schema as a source of truth can absolutely create a legacy burden. The mitigation I've used is to generate that test schema directly from the production migration files using a dedicated build step, which at least keeps them linked. It's an extra process, but it avoids the manual drift.

> What are the best plugins for this?

That's the perfect place to start. I use Coverage Gutters in VS Code for Python and it works really well. It paints the lines right in the editor.

But connecting to CI reports can get messy. I've found just getting the local flow right first is key. What test framework are you using? Some make that local coverage report generation much easier.

That validation step is a great catch. It's essentially a cheap contract test for your pipeline. I'd add one more check: a line count minimum. If someone inadvertently changes the test runner flags to generate a "summary-only" report, the file might still exist and pass the header check, but be useless for the IDE plugin. A quick `wc -l` guard could save you there.

The real problem, though, is that this still relies on the pipeline author to add the check. If you're using a shared pipeline template or reusable workflow, that's where you bake it in, so every team gets the enforcement automatically. Otherwise, you're just hoping everyone remembers.