<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Coverlet on Daniel Genezini</title><link>https://genezini.com/tags/coverlet/</link><description>Recent content in Coverlet on Daniel Genezini</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><copyright>2022 Daniel Genezini All rights reserved</copyright><lastBuildDate>Thu, 03 Nov 2022 08:10:00 -0300</lastBuildDate><atom:link href="https://genezini.com/tags/coverlet/index.xml" rel="self" type="application/rss+xml"/><item><title>Analyzing and enforcing .NET code coverage with coverlet</title><link>https://genezini.com/blog/p/analyzing-and-enforcing-.net-code-coverage-with-coverlet/</link><pubDate>Thu, 03 Nov 2022 08:10:00 -0300</pubDate><guid>https://genezini.com/blog/p/analyzing-and-enforcing-.net-code-coverage-with-coverlet/</guid><description>&lt;img src="https://genezini.com/blog/p/analyzing-and-enforcing-.net-code-coverage-with-coverlet/cover.png" alt="Featured image of post Analyzing and enforcing .NET code coverage with coverlet" /> Automated software tests are a requirement for ensuring we are delivering a product with quality to our users. It helps in finding bugs and requirements not fulfilled at development time, but also decreases the cost of maintenance by making the future changes to our code safer. Besides, the act of writing testable code alone increases the quality of the code we are writing because testable code has to be decoupled.
In this last post of this series, I'll show how to analyze and enforce a minimum code coverage in our applications, and how to use integration tests to increase our testing surface.</description></item></channel></rss>