Parallel item creation for test-data creators - #39
Open
SirCotare wants to merge 3 commits into
Open
Conversation
Opt-in per call site via parallel(), opt-out via sequential(). The it.aboutbits.testing.testdata.parallel-by-default system property flips the default, so a whole suite can run parallel without touching call sites. The result list keeps index order; worker failures are rethrown unwrapped.
Replaces the hand-rolled field-plus-sameXyz-flag memoization in creators: fixed, shared, and per-item modes in one holder. resolve() is safe under parallel item creation - a shared value is created exactly once, per-item creation stays unsynchronized.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
In finstral-composer-api, DB-backed test setups spend most of their time in sequential
given.many(n)loops. Measured against the real Oracle testcontainer there, parallelizing the per-item loop gives:many(n)many(n).parallel()What
TestDataCreator.parallel()/.sequential(): opt-in/out per call site; theit.aboutbits.testing.testdata.parallel-by-defaultsystem property flips the default for a whole suite (intended for a release-candidate experiment run in composer CI).TestDataDependency<T>: one holder for a creator dependency in its three modes (fixed / shared / per item), replacing the hand-rolledfield + sameXyz flagcheck-then-act memoization that races under parallel creation. Shared values resolve exactly once; per-item resolution stays unsynchronized.Review notes
parallel().ModifiableTestDataCreator's mutator bookkeeping stays correct under parallelism: writes happen-before theFuture.get()joins.parallel()/sequential()are@CanIgnoreReturnValue(not@CheckReturnValue) deliberately: a subclass may pin a mode in its constructor without chaining.Unit tests cover index order, real concurrency, failure propagation, the property flip, and exactly-once shared resolution under 8 threads. Not run: any downstream project suite — composer runs its own CI experiment against a release candidate.
🤖 Generated with Claude Code