feat(assertion): Add PrepAndExpectedTestData value type - #971
Conversation
Reviewer's GuideAdds PrepAndExpectedTestData as an immutable bundle for verification, prep, and expected test inputs, then exposes additive default PrepAndExpectedTestCase overloads that delegate to the existing array-based API; tests and documentation cover immutability, convenience factories, value semantics, forwarding, and runtime behavior. Sequence diagram for bundled test data delegationsequenceDiagram
participant Caller
participant TestCase as PrepAndExpectedTestCase
participant Data as PrepAndExpectedTestData
Caller->>TestCase: runTest(Data, testSteps)
TestCase->>Data: getVerifyTableDefinitions()
Data-->>TestCase: copied definitions
TestCase->>Data: getPrepDataFiles()
Data-->>TestCase: copied prep files
TestCase->>Data: getExpectedDataFiles()
Data-->>TestCase: copied expected files
TestCase->>TestCase: runTest(definitions, prep, expected, testSteps)
TestCase-->>Caller: result
File-Level Changes
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reachedNext included review available in 39 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (1)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (8)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughAdds immutable ChangesPrep and expected test data bundle
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to This adds an immutable bundled test-data argument and convenience overloads while preserving the existing array-based execution paths. The documented behavior is covered by tests, with no identified merge-blocking risk. Sequence Diagram(s)sequenceDiagram
participant TestCase
participant PrepAndExpectedTestCase
participant ExistingArrayAPI
TestCase->>PrepAndExpectedTestCase: call bundle-based overload
PrepAndExpectedTestCase->>PrepAndExpectedTestCase: unpack bundled arrays
PrepAndExpectedTestCase->>ExistingArrayAPI: delegate arrays and test steps
ExistingArrayAPI-->>TestCase: return result or update test state
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 42 functions across 5 files. (3 skipped: 3 unsupported.) ✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Hey - I've found 1 issue
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="src/main/java/org/dbunit/PrepAndExpectedTestData.java" line_range="44-46" />
<code_context>
+ * <p>
+ * Instances are immutable: the constructor copies each array in, every getter
+ * copies its array out, and a {@code null} array is normalized to an empty one.
+ * The {@link VerifyTableDefinition} instances the array holds are shared rather
+ * than copied, matching how callers already use them - as {@code static final}
+ * constants treated as effectively immutable.
+ *
+ * @author Jeff Jensen
</code_context>
<issue_to_address>
**issue (bug_risk):** `PrepAndExpectedTestData` is not fully immutable: it only copies the `VerifyTableDefinition[]` container, while sharing each mutable `VerifyTableDefinition` instance. Mutating a definition after bundling changes the scenario represented by the value and can also change its `equals`/`hashCode` result after it has been placed in a hash-based collection.
**Triggers:** When a caller reuses a `VerifyTableDefinition` and later changes its verifier or sorting configuration.
**Suggested fix:** Deep-copy or otherwise freeze the contained `VerifyTableDefinition` instances, or narrow the immutability/value-type contract to state that the element objects must not be mutated after construction.
</issue_to_address>Sourcery assessment
Approval pending. 1 finding to address first.
Blocking findings: src/main/java/org/dbunit/PrepAndExpectedTestData.java:46
PrepAndExpectedTestCase.configureTest(), preTest(), and runTest() each take the same (VerifyTableDefinition[], String[] prep, String[] expected) triple. It describes one test scenario and is meaningless split apart, yet in a data-driven test it propagates through the @ParameterizedTest signature, every @MethodSource row, and any row-factory method built to keep those rows readable. PrepAndExpectedTestData bundles the triple into one immutable value: * Defensive-copies each array in and out; normalizes null to empty. * A NONE constant and a prepOnly(String...) factory cover the common partial cases, replacing a separate empty constant per array type. * equals/hashCode/toString for whole-object assertions in tests. PrepAndExpectedTestCase gains default configureTest(PrepAndExpectedTestData), preTest(PrepAndExpectedTestData), and runTest(PrepAndExpectedTestData, PrepAndExpectedTestCaseSteps) overloads that unpack the bundle and delegate to the existing array methods. Purely additive: no existing signature changes, no implementor breaks, and DefaultPrepAndExpectedTestCase needs no edit. Complements the annotation-driven configuration of issue 753, which serves configuration fixed per test method rather than varying per invocation. Refs: 938 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RgQW5ydR5upi3SiuW2oEu2
a6ed9ac to
b0181b5
Compare
PrepAndExpectedTestCase.configureTest(), preTest(), and runTest() each take the same (VerifyTableDefinition[], String[] prep, String[] expected) triple. It describes one test scenario and is meaningless split apart, yet in a data-driven test it propagates through the @ParameterizedTest signature, every @MethodSource row, and any row-factory method built to keep those rows readable.
PrepAndExpectedTestData bundles the triple into one immutable value:
PrepAndExpectedTestCase gains default configureTest(PrepAndExpectedTestData), preTest(PrepAndExpectedTestData), and runTest(PrepAndExpectedTestData, PrepAndExpectedTestCaseSteps) overloads that unpack the bundle and delegate to the existing array methods. Purely additive: no existing signature changes, no implementor breaks, and
DefaultPrepAndExpectedTestCase needs no edit.
Complements the annotation-driven configuration of issue 753, which serves configuration fixed per test method rather than varying per invocation.
Refs: 938
Claude-Session: https://claude.ai/code/session_01RgQW5ydR5upi3SiuW2oEu2
Summary by Sourcery
Bundle preparation, expected-data, and verification settings into an immutable test value and expose additive PrepAndExpectedTestCase overloads for data-driven scenarios.
New Features:
Enhancements:
Documentation:
Tests:
Summary by CodeRabbit
New Features
Documentation
Tests