daily-email: add 2023-11-02
Is code coverage an objective or guideline?
This commit is contained in:
parent
b078fc8ee9
commit
5d87e1bed4
25
src/content/daily-email/2023-11-02.md
Normal file
25
src/content/daily-email/2023-11-02.md
Normal file
|
@ -0,0 +1,25 @@
|
|||
---
|
||||
title: >
|
||||
Is code coverage an objective or guideline?
|
||||
pubDate: 2023-11-02
|
||||
permalink: >
|
||||
archive/2023/11/02/is-code-coverage-an-objective-or-guideline
|
||||
tags:
|
||||
- software-development
|
||||
- automated-testing
|
||||
- test-driven-development
|
||||
---
|
||||
|
||||
Many development teams and projects use code coverage - e.g. how many lines of code are covered by automated tests - as an objective, and saying it must be 100% or another percentage.
|
||||
|
||||
But is this an effective metric?
|
||||
|
||||
In the same way as deleting failing tests to fix a pipeline, a code coverage amount can be faked.
|
||||
|
||||
With this in mind, what if, instead of setting an objective such as 100% code coverage, you used it as a guideline?
|
||||
|
||||
If you're working on a legacy project, what if you set a minimum code coverage amount as a guideline to ensure any new code has tests by not dropping under that level?
|
||||
|
||||
Would that be better than saying every line of code needs to be covered?
|
||||
|
||||
Code coverage is something I'm thinking of using more, so I want to know what you think.
|
Loading…
Reference in a new issue