A blog by Nikolaos Georgiou

Posts tagged with code coverage

  • Code coverage on integration tests?

    Aug 11, 2018

    Should you collect and measure code coverage on integration tests or only unit tests? In this post I’ll share some thoughts on this topic.

  • Exclude class from JaCoCo coverage

    Apr 21, 2018

    JaCoCo’s exclude configuration works with classes, so the .class extension is important when specifying the path.

  • Code coverage in .NET Core and SonarCloud

    Feb 17, 2018

    In this post, I’m creating a code coverage report for a .NET Core project. I’m also using SonarCloud to analyze the project’s quality.

  • Adding code coverage with nyc

    Dec 29, 2017

    In this post, I’ll add code coverage to the build pipeline and configure TeamCity to break the build if the code coverage drops.

  • Code Coverage with JaCoCo

    Mar 12, 2017

    Code Coverage is a useful set of metrics that show you how much of your code you’re impacting during testing. It doesn’t say much about the quality of your tests (you can read more in the old post What is code coverage?), but a 30% coverage is definitely worse than 90%. Let’s see how we can use JaCoCo to see our code coverage in the Java world. We’ll check a few options to use it, such as using it manually, using it within a CI, breaking the build with it, etc. The assumption is we’re working with a Maven project.

  • What is code coverage?

    May 7, 2016

    Last time we had a look at test driven development and our calculator learned how to do multiplication. In this post, we’ll add division and talk a bit about code coverage and unit test quality.

  • Code coverage for open source .NET with AppVeyor and Coveralls

    Mar 19, 2016

    Code coverage is a useful metric of the quality of your code. It shows how much code is being covered by unit tests. It doesn’t necessarily mean that the unit tests are well written, but no metric can probably tell you that. However, aiming for a specific code coverage, let’s say 70%, is a good practice, because failing to meet the goal might mean somebody didn’t write enough unit tests.