We have a lot of legacy code that have poor test coverage. We wish that all new code that is checked in through pull requests has (close to) full test coverage. What is the best approach or tools to achieve this?

We're using git-tfs, .NET C# and TypeScript. And we'd like this to be part of the code review process and prevent developers (or at least give a warning) to check in with insufficient test coverage.

  • How are you measuring the test coverage? Commented Jan 22, 2018 at 17:46
  • @DanCornilescu We're using MSTest and some built in test coverage in TFS Build. If other test/build tools will help achive this then I'm all ears! Commented Jan 23, 2018 at 8:32

1 Answer 1


IMHO from the workflow prospective code coverage measurements are fundamentally similar to builds, smoketests or any other types of QA checks and can thus be performed in similar manner. I can see several options:

  • include them in the PR verification path, just like builds and/or smoketests, similarly positioned relative to the code review stage.
  • include them as a step in the pre-commit gating system, if you use one - most effective IMHO, especially for large projects where scalability comes into play (mentioned in my answer to How do you scale your integration testing?).
  • include them in the CI pipeline, maybe on a parallel execution path if they're lengthy, to not add too much to the total CI execution time. Very useful to use these runs as up2date baselines for results comparisons for the other 2 cases listed above.

I'm not familiar with MS tools, but if MSTest doesn't offer good integration with the other tools in your workflow you could build custom wrappers to implement a typical submit/execute API with a pass/fail result (or set of results) which most tools can integrate with.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.