Skip to content

Context-scope the command stub fixtures #506

Description

@josegonzalez

Description of feature

commands/stub_task_test.go drives the apply and plan executors without a server by registering a dokku_stub task that reads its canned result out of a process-wide map. stubFixtures is a map[string]StubFixture keyed by a short caller-chosen string, guarded by stubMu, and stubReset() wipes the whole map - which every test calls as its first deferred statement.

The mutex means there is no data race, but the map is still one shared namespace. Two tests running at the same time and both calling stubSet("a", ...) clobber each other, and either one's stubReset() erases the other's fixtures mid-run. Sixteen test files depend on it, so this is the largest of the three things standing between commands/ and t.Parallel().

The fix is the same move ContextWithRunner made for the exec seam: StubTask reads its fixture off the context rather than the package map, so each test installs its own set and the key namespace is per-test rather than per-process. Deriving keys from t.Name() would paper over the collision without removing the shared map, and would still leave stubReset() erasing another test's state.

Independent of #502's ContextWithRunner migration - the stub does not use the exec seam at all - and worth doing separately from the argv/working-directory work in #505, which it does not depend on either. All three are prerequisites for the commands/ half of #502.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions