From cd110e0c3619c43d3a058ed23ec38e4f303f8a7e Mon Sep 17 00:00:00 2001 From: mfenderov Date: Mon, 20 May 2024 20:13:46 +0200 Subject: [PATCH] feat: minor re-arrangement --- posts/20240422-testing-guideline.md | 77 +++++++++++++++-------------- 1 file changed, 39 insertions(+), 38 deletions(-) diff --git a/posts/20240422-testing-guideline.md b/posts/20240422-testing-guideline.md index 26bf69d..126fb39 100644 --- a/posts/20240422-testing-guideline.md +++ b/posts/20240422-testing-guideline.md @@ -960,6 +960,45 @@ For example: Overall, architectural tests should be quite deep in your toolbox. Don’t just wave it left and right. +### Avoid fake test coverage + +* Test coverage is a useful metric that can help **identify** untested code paths + +* Test coverage is **just a metric**, and **should not** be the sole purpose of writing tests + +* Writing tests solely to increase test coverage can lead to dangerous **fake** and **meaningless** coverage, where + tests are written to simply execute the code paths with no actually asserting or verifying results + +* Fake coverage leads to a **false** sense of security, where developers think they have thoroughly tested their code + when in reality they are not + +* Using tools like Sonar or other static code analyzers **can help** identify missed execution paths, but they **should + not** be used to enforce writing tests for the sake of coverage + +* Focus on writing tests that **actually** **test** functionality and ensure that code is working as expected, + rather than just trying to increase test coverage + +* Good test coverage alone **does not** guarantee the quality or correctness of code + +* **It is better to have no test coverage than a fake one.** + With no coverage, at least, there is an incentive to write tests + +### How to identify “fake” tests? + +* Try to break the test — if the only way to break the test is to delete some lines of code, it might be a fake + test + +* Vague argument matchers - screams fake + +* Messy overly complex tests — there’s a high probability that some coverage is fake + +* Tests without any meaningful assertions or verifications - 100% fake + +* Tests that test getters and setters — it’s not fake, but a horrible way to increase the test coverage + +* Tests that do not follow this testing guideline — most certainly fake 😉. + + ### References * [https://www.baeldung.com/java-unit-testing-best-practices](https://www.baeldung.com/java-unit-testing-best-practices) @@ -1103,44 +1142,6 @@ But everything else signals a high level of unprofessionalism from the engineers * [https://maven.apache.org/surefire/maven-failsafe-plugin/](https://maven.apache.org/surefire/maven-failsafe-plugin/) -### Avoid fake test coverage - -* Test coverage is a useful metric that can help **identify** untested code paths - -* Test coverage is **just a metric**, and **should not** be the sole purpose of writing tests - -* Writing tests solely to increase test coverage can lead to dangerous **fake** and **meaningless** coverage, where - tests are written to simply execute the code paths with no actually asserting or verifying results - -* Fake coverage leads to a **false** sense of security, where developers think they have thoroughly tested their code - when in reality they are not - -* Using tools like Sonar or other static code analyzers **can help** identify missed execution paths, but they **should - not** be used to enforce writing tests for the sake of coverage - -* Focus on writing tests that **actually** **test** functionality and ensure that code is working as expected, - rather than just trying to increase test coverage - -* Good test coverage alone **does not** guarantee the quality or correctness of code - -* **It is better to have no test coverage than a fake one.** - With no coverage, at least, there is an incentive to write tests - -### How to identify “fake” tests? - -* Try to break the test — if the only way to break the test is to delete some lines of code, it might be a fake - test - -* Vague argument matchers - screams fake - -* Messy overly complex tests — there’s a high probability that some coverage is fake - -* Tests without any meaningful assertions or verifications - 100% fake - -* Tests that test getters and setters — it’s not fake, but a horrible way to increase the test coverage - -* Tests that do not follow this testing guideline — most certainly fake 😉. - # Other materials * [https://www.youtube.com/watch?v=1Z\_h55jMe-M](https://www.youtube.com/watch?v=1Z_h55jMe-M) - must watch, if you’re