--- title: Why 90% Code Coverage Doesn’t Mean Your Tests Are Good description: High code coverage percentages do not guarantee good tests, since coverage only measures whether a line executed, not whether a test is deterministic,... canonical: https://daily.dev/posts/why-90-code-coverage-doesn-t-mean-your-tests-are-good-2fwmyd7ne twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Why 90% Code Coverage Doesn’t Mean Your Tests Are Good | daily.dev og:description: High code coverage percentages do not guarantee good tests, since coverage only measures whether a line executed, not whether a test is deterministic,... og:url: https://daily.dev/posts/why-90-code-coverage-doesn-t-mean-your-tests-are-good-2fwmyd7ne og:image: https://api.daily.dev/og/posts/2fWMyD7ne.png og:image:alt: Why 90% Code Coverage Doesn’t Mean Your Tests Are Good og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Why 90% Code Coverage Doesn’t Mean Your Tests Are Good **[SD Times](https://daily.dev/sources/sdtimes)** · 11 min read · 0 upvotes · 1 comments ## Summary High code coverage percentages do not guarantee good tests, since coverage only measures whether a line executed, not whether a test is deterministic, meaningful, or trustworthy. Two codebases can both show 92% coverage while one has isolated, reliable tests and the other has flaky, duplicate, or fake-dependent tests. AI coding assistants make this worse by rapidly generating syntactically different tests that validate identical scenarios, inflating test counts and coverage without adding real confidence. The piece argues teams need a 'test review' practice alongside coverage, checking for isolation, duplication, unused mocks/fakes, and whether failures indicate real defects, with mutation testing suggested as a stronger signal of test effectiveness. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Does 100% code coverage mean my tests are good? No. Code coverage only measures which lines of production code executed during testing, not whether the tests validate meaningful behavior. A line can be executed by a fragile, redundant, or nearly useless test and still count toward coverage, so high coverage is a necessary but not sufficient indicator of test suite quality. _Developers rethinking their test strategy beyond raw coverage numbers can find deeper testing discussions on daily.dev._ ### How does AI-generated test code affect code coverage metrics and test suite quality? AI coding assistants can rapidly generate many syntactically different tests that exercise identical behavior with the same inputs and assertions, inflating test counts and marginally improving coverage percentages without adding meaningful validation scenarios. Teams using AI-assisted testing need to actively review for duplicate test coverage rather than relying on raw counts or coverage numbers. _Teams adopting AI-assisted test generation can track this evolving practice through daily.dev's testing coverage._ ### What should a test review process check beyond code coverage? A test review should verify that tests are isolated from external dependencies like files, network, and clocks, that fakes and mocks configured in the test are actually invoked by the production code, that each test validates a scenario not already covered by another test, and that a failing test reliably indicates a real defect rather than environmental noise. _Engineers building trustworthy test suites can follow more test review guidance via daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@nark3d** · 0 upvotes > Mutation testing is where I think this gets oversold. It only tells you the suite noticed a change, so the mutation score inherits the same gap as the coverage number it was meant to replace. For it to hold, the suite's assertions would have to be tied to observable outputs first, which is the review practice the piece is really asking for. The isolation and duplication checks are the ones that pay off, because those are things a person can look at and call. ## Similar posts on daily.dev - [Making your code base better will make your code coverage worse](https://daily.dev/posts/making-your-code-base-better-will-make-your-code-coverage-worse-ovk4jq9bx) · Stack Overflow Blog · 1 upvotes · 0 comments - [JetBrains Qodana](https://daily.dev/posts/jetbrains-qodana-bthpiwtj0) · JetBrains · 0 upvotes · 0 comments - [Critiquing tests](https://daily.dev/posts/critiquing-tests-wycci2evo) · ploeh blog · 2 upvotes · 0 comments --- Tags: [#testing](https://daily.dev/tags/testing), [#ai-coding](https://daily.dev/tags/ai-coding) [View this post on daily.dev](https://daily.dev/posts/why-90-code-coverage-doesn-t-mean-your-tests-are-good-2fwmyd7ne) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Why 90% Code Coverage Doesn’t Mean Your Tests Are Good","url":"https://daily.dev/posts/why-90-code-coverage-doesn-t-mean-your-tests-are-good-2fwmyd7ne","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/why-90-code-coverage-doesn-t-mean-your-tests-are-good-2fwmyd7ne"},"datePublished":"2026-09-11T17:25:36.124Z","dateModified":"2026-10-15T02:22:08.713Z","description":"High code coverage percentages do not guarantee good tests, since coverage only measures whether a line executed, not whether a test is deterministic,...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/0fe57d6a16240f826d186ad408e929d6?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/0fe57d6a16240f826d186ad408e929d6?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"SD Times","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"SD Times","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/d803c981e67b4edf928840534e1e1382","url":"https://daily.dev/sources/sdtimes"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/why-90-code-coverage-doesn-t-mean-your-tests-are-good-2fwmyd7ne","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"testing,ai-coding","timeRequired":"PT11M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"SD Times","item":"https://daily.dev/sources/sdtimes"},{"@type":"ListItem","position":3,"name":"Why 90% Code Coverage Doesn’t Mean Your Tests Are Good"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/why-90-code-coverage-doesn-t-mean-your-tests-are-good-2fwmyd7ne","comment":[{"@type":"Comment","text":"Mutation testing is where I think this gets oversold. It only tells you the suite noticed a change, so the mutation score inherits the same gap as the coverage number it was meant to replace. For it to hold, the suite’s assertions would have to be tied to observable outputs first, which is the review practice the piece is really asking for. The isolation and duplication checks are the ones that pay off, because those are things a person can look at and call.","datePublished":"2026-09-20T10:24:58.991Z","url":"https://daily.dev/posts/2fWMyD7ne#c-61liLvSlG","author":{"@type":"Person","name":"Adam","url":"https://daily.dev/nark3d","image":"https://avatars.githubusercontent.com/u/2162621?v=4"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/why-90-code-coverage-doesn-t-mean-your-tests-are-good-2fwmyd7ne#faq","mainEntity":[{"@type":"Question","name":"Does 100% code coverage mean my tests are good?","acceptedAnswer":{"@type":"Answer","text":"No. Code coverage only measures which lines of production code executed during testing, not whether the tests validate meaningful behavior. A line can be executed by a fragile, redundant, or nearly useless test and still count toward coverage, so high coverage is a necessary but not sufficient indicator of test suite quality. Developers rethinking their test strategy beyond raw coverage numbers can find deeper testing discussions on daily.dev."}},{"@type":"Question","name":"How does AI-generated test code affect code coverage metrics and test suite quality?","acceptedAnswer":{"@type":"Answer","text":"AI coding assistants can rapidly generate many syntactically different tests that exercise identical behavior with the same inputs and assertions, inflating test counts and marginally improving coverage percentages without adding meaningful validation scenarios. Teams using AI-assisted testing need to actively review for duplicate test coverage rather than relying on raw counts or coverage numbers. Teams adopting AI-assisted test generation can track this evolving practice through daily.dev's testing coverage."}},{"@type":"Question","name":"What should a test review process check beyond code coverage?","acceptedAnswer":{"@type":"Answer","text":"A test review should verify that tests are isolated from external dependencies like files, network, and clocks, that fakes and mocks configured in the test are actually invoked by the production code, that each test validates a scenario not already covered by another test, and that a failing test reliably indicates a real defect rather than environmental noise. Engineers building trustworthy test suites can follow more test review guidance via daily.dev."}}]} ```