--- title: Caller-specific coverage | daily.dev description: Ned Batchelder explores a new coverage.py feature idea: per-caller coverage measurement. When refactoring repeated error-handling logic into a shared helper... canonical: https://daily.dev/posts/caller-specific-coverage-5ngt3pjz9 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Caller-specific coverage | daily.dev og:description: Ned Batchelder explores a new coverage.py feature idea: per-caller coverage measurement. When refactoring repeated error-handling logic into a shared helper... og:url: https://daily.dev/posts/caller-specific-coverage-5ngt3pjz9 og:image: https://api.daily.dev/og/posts/5ngt3pjZ9.png og:image:alt: Caller-specific coverage 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. # Caller-specific coverage **[Planet Python](https://daily.dev/sources/planetpython)** · 4 min read · 2 upvotes · 1 comments ## Summary Ned Batchelder explores a new coverage.py feature idea: per-caller coverage measurement. When refactoring repeated error-handling logic into a shared helper function, traditional coverage loses the ability to verify each call site was tested for both success and failure paths. A proof-of-concept decorator uses coverage.py's dynamic contexts and Python's inspect module to start a new context named after the calling location, enabling branch coverage to be tracked separately per caller. The approach works but has limitations: per-caller contexts overwrite existing test-name contexts, post-processing is needed to surface missing lines per caller, and the decorator currently must be added to source code rather than driven through coverage configuration. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How can I get coverage.py to report code coverage separately for each caller of a shared function? A decorator can use coverage.py's dynamic contexts to switch to a new context named after the calling file and line number before the function runs, then restore the previous context afterward. This requires calling coverage.Coverage.current().switch_context() with a context string like per_caller:funcname:file:lineno, letting the HTML report show coverage broken down by caller location instead of aggregated across all callers. _Developers refining test coverage strategies can find implementation patterns like this discussed on daily.dev._ ### Why does refactoring repeated validation logic into a shared helper function reduce the usefulness of code coverage reports? When each call site has its own inline error-raising code, coverage measurement shows exactly which specific cases were tested for failure. Moving that logic into a single shared helper function means coverage only shows that some caller exercised the failure branch, not that every individual caller was tested, because the branch is now measured once in aggregate rather than per call site. _Anyone weighing DRY refactors against test visibility can track these tradeoffs via daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@trevorsuna** · 0 upvotes > Per-caller contexts recover information that normal branch coverage loses after a helper refactor. The feature will really click when reports surface only the missing caller-path pairs and configuration can enable it without source decorators, keeping CI output focused. ## Similar posts on daily.dev - [What's type-coverage, and why should I care?](https://daily.dev/posts/what-s-type-coverage-and-why-should-i-care--br4v8jndh) · Pyrefly: A Fast Python Type Checker and Language Server \| Pyrefly · 0 upvotes · 0 comments - [Three releases, one new organization](https://daily.dev/posts/three-releases-one-new-organization-azbbcz4no) · Planet Python · 0 upvotes · 0 comments - [Coding Agents Don’t Need Bigger Context Windows — They Need a Context Compiler](https://daily.dev/posts/coding-agents-don-t-need-bigger-context-windows-they-need-a-context-compiler-kef8o2bp5) · Towards Data Science · 0 upvotes · 0 comments --- Tags: [#python](https://daily.dev/tags/python), [#testing](https://daily.dev/tags/testing) [View this post on daily.dev](https://daily.dev/posts/caller-specific-coverage-5ngt3pjz9) ```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":"Caller-specific coverage","url":"https://daily.dev/posts/caller-specific-coverage-5ngt3pjz9","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/caller-specific-coverage-5ngt3pjz9"},"datePublished":"2026-08-09T21:50:38.147Z","dateModified":"2026-09-14T06:04:24.314Z","description":"Ned Batchelder explores a new coverage.py feature idea: per-caller coverage measurement. When refactoring repeated error-handling logic into a shared helper...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/98211259ee4e7f1a849fc25dc52ad00d?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/98211259ee4e7f1a849fc25dc52ad00d?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Planet Python","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":"Planet Python","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/eac3cc584cb043b5a242d13752bd3d0c","url":"https://daily.dev/sources/planetpython"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/caller-specific-coverage-5ngt3pjz9","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"python,testing","timeRequired":"PT4M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Planet Python","item":"https://daily.dev/sources/planetpython"},{"@type":"ListItem","position":3,"name":"Caller-specific coverage"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/caller-specific-coverage-5ngt3pjz9","comment":[{"@type":"Comment","text":"Per-caller contexts recover information that normal branch coverage loses after a helper refactor. The feature will really click when reports surface only the missing caller-path pairs and configuration can enable it without source decorators, keeping CI output focused.","datePublished":"2026-08-10T02:45:48.429Z","url":"https://daily.dev/posts/5ngt3pjZ9#c-kyDV5rVtI","author":{"@type":"Person","name":"Trevor Suna","url":"https://daily.dev/trevorsuna","image":"https://media.daily.dev/image/upload/s--dZ7gXxpp--/f_auto/v1784081551/avatars/avatar_EMoP47rpuw8DNjhp6R1b6?_a=BAMAMicg0"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/caller-specific-coverage-5ngt3pjz9#faq","mainEntity":[{"@type":"Question","name":"How can I get coverage.py to report code coverage separately for each caller of a shared function?","acceptedAnswer":{"@type":"Answer","text":"A decorator can use coverage.py's dynamic contexts to switch to a new context named after the calling file and line number before the function runs, then restore the previous context afterward. This requires calling coverage.Coverage.current().switch_context() with a context string like per_caller:funcname:file:lineno, letting the HTML report show coverage broken down by caller location instead of aggregated across all callers. Developers refining test coverage strategies can find implementation patterns like this discussed on daily.dev."}},{"@type":"Question","name":"Why does refactoring repeated validation logic into a shared helper function reduce the usefulness of code coverage reports?","acceptedAnswer":{"@type":"Answer","text":"When each call site has its own inline error-raising code, coverage measurement shows exactly which specific cases were tested for failure. Moving that logic into a single shared helper function means coverage only shows that some caller exercised the failure branch, not that every individual caller was tested, because the branch is now measured once in aggregate rather than per call site. Anyone weighing DRY refactors against test visibility can track these tradeoffs via daily.dev."}}]} ```