Skip to content

RFC: Migrate Test Framework from sclevine/spec#341

Open
jkutner wants to merge 2 commits into
mainfrom
jkutner/migrate-tests-from-slevine-spec
Open

RFC: Migrate Test Framework from sclevine/spec#341
jkutner wants to merge 2 commits into
mainfrom
jkutner/migrate-tests-from-slevine-spec

Conversation

@jkutner

@jkutner jkutner commented Jun 25, 2026

Copy link
Copy Markdown
Member

Signed-off-by: Joe Kutner <jpkutner@gmail.com>
@buildpack-bot

Copy link
Copy Markdown
Member

Maintainers,

As you review this RFC please queue up issues to be created using the following commands:

/queue-issue <repo> "<title>" [labels]...
/unqueue-issue <uid>

Issues

(none)

@hone

hone commented Jun 27, 2026

Copy link
Copy Markdown
Member

@jkutner are you wanting to scope this just to lifecycle or is this just the first step to also cover pack and all other repos in the buildpacks project?

@jkutner

jkutner commented Jun 29, 2026

Copy link
Copy Markdown
Member Author

@hone i want to eventually hit them all, but thought i might start small. do you think I should reframe the RFC to be about all of them? or do an experiment first?

@jkutner

jkutner commented Jul 1, 2026

Copy link
Copy Markdown
Member Author

Here's a Draft PR for Phase 1

Signed-off-by: Joe Kutner <jpkutner@gmail.com>
@jkutner

jkutner commented Jul 6, 2026

Copy link
Copy Markdown
Member Author

@hone @jabrown85 fyi updated to expand scope to all buildpacks org repos that use sclevine/spec

})
```

**Decision criteria**: If any `it()` within the scope mutates the state set up by `it.Before()`, use Option A. If all `it()` blocks only read the state, Option B is safe and more concise.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds like we're going to employ both of these depending on the decision criteria/


**Disadvantages:**
- `SetupTest()` runs for ALL test methods in a suite, creating a fundamental mismatch with scoped `it.Before()`. The 223 scoped setup blocks either require proliferating many small suite structs per file (e.g., `RebaserForceSuite`, `RebaserNoForceSuite`) or using `s.Run()` subtests with inline setup -- which negates the suite benefit.
- Introduces an OOP mental model (struct fields, method receivers, embedding) that is not idiomatic Go testing.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is the idiomatic way to do this?


3. **What is the threshold for choosing Option A (per-test setup function) vs. Option B (top-of-closure setup)?** A clear guideline is needed for the 223 scoped `it.Before` blocks to ensure consistency across the codebase.

4. **Should the AST transformation tool be contributed to the community?** Other projects outside the buildpacks organization that use `sclevine/spec` may benefit from a migration tool. Within the organization, the tool will live in `lifecycle/tools/spec-migrate` during the migration and be removed once all repos are converted (or, alternatively, promoted to a small standalone repo before removal).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think it's fine to just make a repo for it in the buildpacks org.


5. **How should the `each()` helper in `buildpack/build_test.go` (lifecycle) be restructured?** Table-driven tests are the most idiomatic approach but change the test's conceptual structure. Similar helpers in other repos follow the same decision.

6. **What order should the repos be migrated in?** Lifecycle is the natural first target because it exercises every pattern (deep nesting, scoped setup, custom helpers). After lifecycle, order is flexible; small repos (`registry-api`, `imgutil`) offer quick wins, while `pack` benefits most from the settled tooling.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does it make sense to start with a small repo first?

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants