Problem
Worker plugins (worker.Options.Plugins) do not apply in the test environments: TestWorkflowEnvironment / TestActivityEnvironment never construct a real worker, so no plugin hook (ConfigureWorker, StartWorker/RunContextBefore, StopWorker/RunContextAfter) ever runs. Anything a plugin contributes — registered workflows/activities, interceptors, converters — must be wired manually in tests.
This splits integration packaging in two: e.g. contrib/googleadk ships NewPlugin as its standard wiring (#2478), but tests must fall back to NewActivities + Register, and that manual path has to stay public (and documented) solely for testability. sdk-python does not have this gap — its test environment runs a real worker, so plugins compose into tests transparently.
Proposal
Let the test environments accept plugins (e.g. honor SetWorkerOptions(worker.Options{Plugins: ...}) or a dedicated setter) and invoke at minimum ConfigureWorker plus the StartWorker/StopWorker run-context hooks around test execution, with the environment's registry backing the plugin registry. That would let a plugin be the single wiring surface for an integration, in production and tests alike — and would unblock deprecating integration-specific manual registration APIs (see discussion on #2478).
Problem
Worker plugins (
worker.Options.Plugins) do not apply in the test environments:TestWorkflowEnvironment/TestActivityEnvironmentnever construct a real worker, so no plugin hook (ConfigureWorker,StartWorker/RunContextBefore,StopWorker/RunContextAfter) ever runs. Anything a plugin contributes — registered workflows/activities, interceptors, converters — must be wired manually in tests.This splits integration packaging in two: e.g.
contrib/googleadkshipsNewPluginas its standard wiring (#2478), but tests must fall back toNewActivities+Register, and that manual path has to stay public (and documented) solely for testability. sdk-python does not have this gap — its test environment runs a real worker, so plugins compose into tests transparently.Proposal
Let the test environments accept plugins (e.g. honor
SetWorkerOptions(worker.Options{Plugins: ...})or a dedicated setter) and invoke at minimumConfigureWorkerplus theStartWorker/StopWorkerrun-context hooks around test execution, with the environment's registry backing the plugin registry. That would let a plugin be the single wiring surface for an integration, in production and tests alike — and would unblock deprecating integration-specific manual registration APIs (see discussion on #2478).