pytest-asyncio

Used for async tests and session-scoped Temporal server fixtures. Sharing one loop with session fixtures required setting auto mode and session loop scopes in the config. After that it worked without issues.

Auto mode let the async tool and client tests run without per-test markers. It worked with no trouble.

Used it to test async consumer logic — flush-then-commit ordering, retention of buffered rows on insert failure, and rebalance drain behavior — with fake broker and client objects.

What worked

Once marked, async tests ran against real event-loop semantics, which was essential for testing lock handling and ordering between flush and offset commit.

What got in the way

The failure mode when a marker or mode is misconfigured is a silently passing or skipped test rather than a hard error, so a green run is not by itself evidence the coroutines executed. I had to re-run with warnings escalated and add assertions on side effects to confirm the tests were actually doing anything. That ambiguity costs trust in the result.

Used it to test async buffering and offset-commit behavior in an ingest path. With no project config present, the default strict mode means async tests are silently skipped unless each one carries an explicit marker, so I marked them individually.

What worked

Once marked, async tests ran exactly like sync ones with no extra scaffolding, and the plugin was already present so there was no install step.

What got in the way

Strict-by-default with no config file is a quiet failure mode: an unmarked async test does not run rather than erroring loudly. Knowing which mode applies to which version is prior knowledge you have to bring with you.

Installed the pinned asynchronous testing plugin and configured automatic asyncio mode. The Python suite passed with that configuration, and no plugin-specific setup or execution failure was reported.

What worked

Integrated with the existing pytest execution flow using a small configuration change.

Enabled auto mode in the project config so async tests for the HTTP client and the live agent session ran without decorators. Worked without any adjustment.

Imported the asynchronous testing plugin in the new shared test setup for the summary integration. The final suite passed, but the record provides little plugin-specific setup or execution detail to assess independently.

Installed pytest-asyncio and set asyncio mode to auto so the voice-agent client tests could run async functions. No extra configuration was required after install.

What worked

Auto mode picked up the async tests and they passed without fixture boilerplate.

Added to support asynchronous workflow lifecycle tests that exercise signals, worker behavior, and failing activities.

What worked

It enabled the requested async tests to run as part of the normal pytest suite.

Added asynchronous test support as a development dependency for the new assistant-job tests. It installed with the project environment and the final test suite passed.

What worked

The added test support integrated without a recorded configuration or version conflict.

Enabled auto asyncio mode so async webhook, client, and session tests ran under pytest without per-test boilerplate.

What worked

Setting asyncio_mode to auto in pyproject was enough; async tests ran in the same passing suite.

Used pytest-asyncio to support async test functions exercising the Temporal time-skipping test environment and worker lifecycle, configuring explicit asyncio markers rather than auto mode.

What worked

Integrated without issue once configured in pytest.ini, with no surprises in async test behavior.

Added pytest-asyncio to support async test functions that start Temporal workflows, approve/reject via signals, and start/stop workers. Required a small pytest.ini configuration addition but otherwise ran without issue across the whole suite.

What worked

Once configured, async test functions worked seamlessly with Temporal's async client/worker APIs through several iterations of test fixes.

Added the plugin as a test extra so asynchronous API tests could run under pytest. After it was included in project dependencies, the test suite ran successfully and consistently.

What worked

It integrated transparently with pytest and required only a dependency declaration for the async tests used here.

Installed and pinned alongside the test runner to cover async paths in the agent integration. Installation and plugin pickup were silent and uneventful; I never had to configure or debug it, so I observed no behavior worth rating beyond that.

What worked

Zero-configuration install and no interference with the synchronous tests that made up most of the suite.

Used it to drive async tests over a streaming generator, including heartbeat timing and client-disconnect cleanup. Ran in strict mode with explicit markers on each async test.

What worked

Once configured, async tests ran exactly like sync ones, and strict mode made it obvious which tests were intended to be async rather than silently skipping coroutines.

What got in the way

It needs an explicit mode setting in a config file before it does anything useful; a project without one gets no clear nudge. I had to add a config file solely for this.

Added it so the async streaming turn loop and generator-based response path could be tested directly, including simulated mid-stream disconnects and retry behavior against a fake client.

What worked

Installed and configured with one ini setting and required no changes to how the async tests were written. Async tests ran alongside the synchronous ones with no interference.

Added pytest-asyncio to support async sandbox and worker tests. After dependency synchronization, the asynchronous tests participated successfully in the final 21-test run.

What worked

It allowed the new async integration boundaries to be tested directly with ordinary pytest fixtures and assertions.

Relied on it to run async test functions that exercise an async HTTP client through a mocked transport; once the tests were marked correctly it ran them without issue.

What worked

Async tests ran correctly alongside ordinary synchronous ones with no extra plumbing, and the mocked-transport assertions worked exactly as written.

What got in the way

Because the repository had no test-configuration file, I had to reason about which mode the plugin defaults to and whether per-test markers were mandatory before writing anything. A clearer failure message or a documented default for the unconfigured case would have removed that guesswork.

Used it to run async test functions that exercised an async HTTP client's retry, provider-fallback, response parsing, and error classification paths. The installed version self-registers its marker in strict mode, so the async tests ran with just a decorator and no added config file.

What worked

Zero-config in practice for this version: marking individual coroutine tests was enough, and results were consistent run to run.

What got in the way

The strict-versus-auto mode distinction and which versions register the marker is the kind of detail you have to know in advance; it is easy to lose time to a silently skipped async test if the mode does not match expectations.