Skip to content

testing: ship adcp.testing.make_request_context + build_asgi_app helpers #516

@bokelley

Description

@bokelley

From the salesagent v3.12 → 4.x migration (SDK_FEEDBACK.md, items #10 and #11).

Two test-DX gaps in adcp.testing/:

1. make_request_context

RequestContext has 11 fields, 4 with <factory> defaults. For unit testing through PlatformHandler, the only thing the handler reads is ctx.account and sometimes ctx.request_id.

Constructing a RequestContext for tests requires guessing which factory defaults are safe. I hit TypeError: unexpected keyword argument 'adopter_request' when I read a docstring that mentioned the field but it's not a constructor parameter. The test-friendly path took several tries.

Ask: ship adcp.testing.make_request_context(account=..., **overrides) with sane defaults and a stable signature documented as the test seam.

2. build_asgi_app

create_adcp_server_from_platform doesn't accept name=, but serve() does.

Building the ASGI app in tests requires going through create_adcp_server_from_platform() → create_mcp_server() and the kwarg surface differs between the two. The current docstring on create_mcp_server is a great implementation reference but it's not framed as the test seam.

Ask: first-class adcp.testing.build_asgi_app(platform, name=...) → ASGIApp helper that's officially the "for tests" way to get a running server.

Acceptance

Adopters writing platform-handler unit tests can:

  1. Construct a RequestContext in one line with no factory-default guessing.
  2. Get an ASGIApp from a platform in one call with the same kwarg surface as serve().

Both helpers live in adcp.testing/ (module already exists with test_helpers.py).

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions