--- title: Phased behaviour in wrapture | daily.dev description: Explains wrapture's phase mechanism for testing code whose behaviour must change mid-test, such as retry loops, circuit breakers, and polling loops. Phases let... canonical: https://daily.dev/posts/phased-behaviour-in-wrapture-wokjckjck twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Phased behaviour in wrapture | daily.dev og:description: Explains wrapture's phase mechanism for testing code whose behaviour must change mid-test, such as retry loops, circuit breakers, and polling loops. Phases let... og:url: https://daily.dev/posts/phased-behaviour-in-wrapture-wokjckjck og:image: https://api.daily.dev/og/posts/wokJckjCK.png og:image:alt: Phased behaviour in wrapture 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. # Phased behaviour in wrapture **[Planet Python](https://daily.dev/sources/planetpython)** · 8 min read · 1 upvotes · 1 comments ## Summary Explains wrapture's phase mechanism for testing code whose behaviour must change mid-test, such as retry loops, circuit breakers, and polling loops. Phases let a binding hand over from one canned behaviour to another based on a call count, a condition evaluated on the call event, exhaustion of a returns_from sequence, or an external advance() trigger from another binding. Compares this to unittest.mock's side_effect list, noting phases can hand off to the real implementation (passes_through) and keep injected values separate from injected exceptions, with a timeline/tape recording which phase handled each call. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How do I test retry logic in Python so the final successful call actually hits the real method instead of a mocked return value? Use wrapture's phase system: configure the first phase to raise the expected failures, then chain a second phase with then(after=N) that calls passes_through(), so calls after the count hand off to the real implementation. This differs from unittest.mock's side_effect list, where every entry is a fabricated outcome and even the final success is canned rather than a real call. _Developers hardening retry tests against false positives can compare mocking approaches on daily.dev._ ### How can I simulate a circuit breaker in a unit test that trips only after the real call actually fails? Set the first phase to passes_through() so real calls run normally, then add a second phase with then(until=fn) where fn checks event.exception is not None, and have that phase raise the circuit-open exception. This lets the failure boundary depend on what the real code actually did rather than a fixed call count, which a plain side_effect list cannot express. _Anyone building resilience tests around circuit breakers can track patterns like this on daily.dev._ ### How do I make one mocked object's behavior change based on what happens in a completely different mocked object during the same test? Attach a stage such as validates_result() to the triggering binding's phase, and inside its callback call the other binding's advance() method to force it into its next phase. In one example a health-check binding cycling through unhealthy results calls remote.advance() once it returns healthy, causing a separate client binding to stop raising ConnectionError and start passing through to the real fetch. _Teams coordinating interdependent mocks across services can explore techniques like this on daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@leonidbugaev** · 0 upvotes > The last success still being a canned return is the part I'd watch. side_effect can fail twice then hand you a fake 200. then(after=N).passes_through() is the first time the retry actually hits the real method. ## Similar posts on daily.dev - [Beyond callables in wrapture](https://daily.dev/posts/beyond-callables-in-wrapture-a41yd6lmi) · Planet Python · 0 upvotes · 0 comments - [Unit testing with wrapture](https://daily.dev/posts/unit-testing-with-wrapture-8myueoz61) · Planet Python · 0 upvotes · 0 comments - [Recording calls with wrapture](https://daily.dev/posts/recording-calls-with-wrapture-hkpb9gqvx) · Planet Python · 0 upvotes · 0 comments - [Live tracing with wrapture](https://daily.dev/posts/live-tracing-with-wrapture-6xkqkaede) · Planet Python · 0 upvotes · 0 comments - [Introducing wrapture](https://daily.dev/posts/introducing-wrapture-ohj3cvcws) · Planet Python · 1 upvotes · 1 comments --- Tags: [#python](https://daily.dev/tags/python), [#testing](https://daily.dev/tags/testing) [View this post on daily.dev](https://daily.dev/posts/phased-behaviour-in-wrapture-wokjckjck) ```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":"Phased behaviour in wrapture","url":"https://daily.dev/posts/phased-behaviour-in-wrapture-wokjckjck","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/phased-behaviour-in-wrapture-wokjckjck"},"datePublished":"2026-09-02T21:50:21.521Z","dateModified":"2026-09-03T00:03:32.124Z","description":"Explains wrapture's phase mechanism for testing code whose behaviour must change mid-test, such as retry loops, circuit breakers, and polling loops. Phases let...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/34fa31dda7bf7e7ffcb57d0ecc62e27f?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/34fa31dda7bf7e7ffcb57d0ecc62e27f?_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/phased-behaviour-in-wrapture-wokjckjck","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"python,testing","timeRequired":"PT8M"} {"@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":"Phased behaviour in wrapture"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/phased-behaviour-in-wrapture-wokjckjck","comment":[{"@type":"Comment","text":"The last success still being a canned return is the part I’d watch. side_effect can fail twice then hand you a fake 200. then(after=N).passes_through() is the first time the retry actually hits the real method.","datePublished":"2026-09-03T06:59:25.089Z","url":"https://daily.dev/posts/wokJckjCK#c-oUDEhXcS6","author":{"@type":"Person","name":"Leonid Bugaev","url":"https://daily.dev/leonidbugaev","image":"https://lh3.googleusercontent.com/a/ACg8ocLhMgurwTmJElWaH9A8Ju8cHvZxgMCDt009jEYkmFCyUGAoaGSw=s96-c"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/phased-behaviour-in-wrapture-wokjckjck#faq","mainEntity":[{"@type":"Question","name":"How do I test retry logic in Python so the final successful call actually hits the real method instead of a mocked return value?","acceptedAnswer":{"@type":"Answer","text":"Use wrapture's phase system: configure the first phase to raise the expected failures, then chain a second phase with then(after=N) that calls passes_through(), so calls after the count hand off to the real implementation. This differs from unittest.mock's side_effect list, where every entry is a fabricated outcome and even the final success is canned rather than a real call. Developers hardening retry tests against false positives can compare mocking approaches on daily.dev."}},{"@type":"Question","name":"How can I simulate a circuit breaker in a unit test that trips only after the real call actually fails?","acceptedAnswer":{"@type":"Answer","text":"Set the first phase to passes_through() so real calls run normally, then add a second phase with then(until=fn) where fn checks event.exception is not None, and have that phase raise the circuit-open exception. This lets the failure boundary depend on what the real code actually did rather than a fixed call count, which a plain side_effect list cannot express. Anyone building resilience tests around circuit breakers can track patterns like this on daily.dev."}},{"@type":"Question","name":"How do I make one mocked object's behavior change based on what happens in a completely different mocked object during the same test?","acceptedAnswer":{"@type":"Answer","text":"Attach a stage such as validates_result() to the triggering binding's phase, and inside its callback call the other binding's advance() method to force it into its next phase. In one example a health-check binding cycling through unhealthy results calls remote.advance() once it returns healthy, causing a separate client binding to stop raising ConnectionError and start passing through to the real fetch. Teams coordinating interdependent mocks across services can explore techniques like this on daily.dev."}}]} ```