Answers: <p>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:</p>
  
  <ul>
  <li>include them in the PR verification path, just like builds and/or smoketests, similarly positioned relative to the code review stage.</li>
  <li>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 <a href="https://softwareengineering.stackexchange.com/questions/282033/how-do-you-scale-your-integration-testing/364382#364382">How do you scale your integration testing?</a>).</li>
  <li>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.</li>
  </ul>
  
  <p>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.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-01-23T21:10:29.683Z
Answers: 2018-01-23T21:10:29.683Z
Answers: Dan Cornilescu
Body: <p>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?</p>
  
  <p>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.</p>
  
Comments: CC BY-SA 3.0
Comments: 2018-01-22T17:46:01.333Z
Comments: How are you measuring the test coverage?
Comments: Dan Cornilescu
Comments: CC BY-SA 3.0
Comments: 2018-01-23T08:32:45.033Z
Comments: @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!
Comments: Arne H. Bitubekk
Tags: <git><tfs>
Title: Test coverage of changed code in pull requests in git-tfs
UserDisplayName: Arne H. Bitubekk
ThreadText: # Test coverage of changed code in pull requests in git-tfs
  
  (Asked by: username_0 on 2018-01-22)
  
  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.
  
  **Tags:** git, tfs
  
  > **Comments:**
  > **username_1**: How are you measuring the test coverage?  
  > **username_0**: @username_1 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!  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-01-23. Score: 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?](https://softwareengineering.stackexchange.com/questions/282033/how-do-you-scale-your-integration-testing/364382#364382)).
  * 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.
  
  
  ---
  
  