Say what configfailurepolicy actually does - #85
Conversation
The `-configfailurepolicy` row promised that `continue` would "continue to execute the remaining tests in the suite". Only a failed `@BeforeTest` behaves that way; `@BeforeClass` and `@BeforeMethod` still skip the test methods they own, and `@BeforeSuite` stops the suite under either policy. The gap between that row and the runner is the sole basis of testng-team/testng#2731. Describe the per-level reality instead, keeping the shipped DTD's framing ("whether to continue attempting Before/After Class/Methods after they've failed once") and adding what each policy invalidates.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe ChangesConfiguration Failure Policy
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This PR only clarifies the documented behavior of the existing configuration-failure policy without changing runtime behavior. No actionable merge-blocking risk remains after normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (1 skipped: 1 unsupported.) ✨ Finishing Touches🧪 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 |
The
-configfailurepolicyrow in the command-line table promises:TestNG does that for exactly one of the four configuration levels. Measured against
master:skipcontinue@BeforeSuite@BeforeTest@BeforeClass@BeforeMethodThe shipped DTD has always had the accurate framing — "whether to continue attempting Before/After Class/Methods after they've failed once or just skip remaining" — so this rewrites the row around that, and spells out what each policy actually invalidates:
continuenarrows a configuration failure to the failing instance (@BeforeClass) or the failing invocation (@BeforeMethod) rather than poisoning the whole class, a failed@BeforeTestinvalidates no instance at all so those test methods run, and a@BeforeSuitefailure stops the suite either way. The failure is reported in every case, socontinuenever turns a broken setup into a green run.The gap between this row and the runner is the sole basis of testng-team/testng#2731, which is still open. Companion PR on the code side, adding a characterization test for the whole matrix and the same wording in the javadoc: testng-team/testng#3426.
Verified with
./mvnw clean package; the rendered cell was checked intarget/html/running_testng.htmlandtarget/html/documentation.html.Summary by CodeRabbit
-configfailurepolicyguidance to clarify how configuration failures affect test execution.