Flaky Run — Quarantined After Two Failures, Build #403 (quarantined)
Build #403 of five consecutive runs of cart.PricingTest, in which appliesTaxToSubtotal is quarantined while the other five cases pass every time. The underlying cause is a rounding boundary that only trips when the tax rate table is reloaded. Read the whole family in build order to reproduce what a flake detector sees.
<?xml version="1.0" encoding="UTF-8"?>
<testsuites>
<testsuite name="cart.PricingTest" tests="6" failures="0" errors="0" skipped="1" time="3.118" timestamp="2026-08-07T09:14:22" hostname="ci-runner-04" id="403">
<testcase classname="cart.PricingTest" name="appliesUnitPrice" time="0.797"/>
<testcase classname="cart.PricingTest" name="appliesTaxToSubtotal" time="0.000">
<skipped message="quarantined: flaky in builds 401 and 402"/>
</testcase>
<testcase classname="cart.PricingTest" name="roundsHalfUpAtTwoDecimals" time="0.495"/>
<testcase classname="cart.PricingTest" name="rejectsNegativeQuantity" time="0.663"/>
<testcase classname="cart.PricingTest" name="appliesBulkRate" time="0.709"/>
<testcase classname="cart.PricingTest" name="appliesCurrencyConversion" time="0.454"/>
</testsuite>
</testsuites>
Specifications
- Seed
- 61200
- Build Number
- 403
- Build Index
- 3
- Builds In Family
- 5
- Suite
- cart.PricingTest
- Tests
- 6
- Flaky Test
- cart.PricingTest.appliesTaxToSubtotal
- Flaky Test Outcome
- skip
- Other Tests Outcome
- pass
- Root Cause
- a rounding boundary that only trips when the tax rate table is reloaded
- Dialect
- surefire
- Line Endings
- LF
Testing contract
Expected to pass- Scenario
- Ingest build #403 as one sample in a five-build flake-detection window.
- Expected result
- appliesTaxToSubtotal is recorded as quarantined in this build while the other five cases pass, so no single build on its own identifies the flake.
What is a .xml file?
XML (Extensible Markup Language) is a verbose, self-describing markup language using nested tags, attributes, and namespaces to represent structured, hierarchical data. It supports schemas, entities, and validation and underlies many document and data formats. It remains common in enterprise, publishing, and interchange contexts.
How to use this file
Use an example XML file to test parsers, namespace and schema validation, XPath queries, and protection against entity-expansion and external-entity attacks.
How to use this file for testing
“Flaky Run — Quarantined After Two Failures, Build #403 (quarantined)” is a deterministic Novus Examples fixture for Error handling, Log parsing, Conversion testing. Deliberately corrupt and invalid files, clearly labelled, for testing how your tool fails.
Documented properties for this file: seed 61200 · LF. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Test and coverage reports document their totals (suites, cases, passes, failures, skips, covered lines) in the spec table. Point your CI dashboard, coverage gate, or report converter at the file and assert those counts survive; format twins carry identical numbers so a conversion can be scored exactly.
Code examples
import xml.etree.ElementTree as ET
tree = ET.parse("quarantine-build-403.xml")
root = tree.getroot()
print(root.tag, [c.tag for c in root][:5])Related files
- xmlFlaky Run — Network Dependency, Build #301 (errored)Build #301 of five consecutive runs of checkout.PaymentTest, in which capturesAuthorisedPayment is errored while the other five cases pass every time. The underlying cause is a real call to the fictional payments host instead of the stub. Read the whole family in build order to reproduce what a flake detector sees.
- xmlFlaky Run — Network Dependency, Build #302 (passing)Build #302 of five consecutive runs of checkout.PaymentTest, in which capturesAuthorisedPayment is passing while the other five cases pass every time. The underlying cause is a real call to the fictional payments host instead of the stub. Read the whole family in build order to reproduce what a flake detector sees.
- xmlFlaky Run — Network Dependency, Build #303 (passing)Build #303 of five consecutive runs of checkout.PaymentTest, in which capturesAuthorisedPayment is passing while the other five cases pass every time. The underlying cause is a real call to the fictional payments host instead of the stub. Read the whole family in build order to reproduce what a flake detector sees.
- xmlFlaky Run — Network Dependency, Build #304 (passing)Build #304 of five consecutive runs of checkout.PaymentTest, in which capturesAuthorisedPayment is passing while the other five cases pass every time. The underlying cause is a real call to the fictional payments host instead of the stub. Read the whole family in build order to reproduce what a flake detector sees.
- xmlFlaky Run — Network Dependency, Build #305 (errored)Build #305 of five consecutive runs of checkout.PaymentTest, in which capturesAuthorisedPayment is errored while the other five cases pass every time. The underlying cause is a real call to the fictional payments host instead of the stub. Read the whole family in build order to reproduce what a flake detector sees.
- xmlFlaky Run — Order Dependent, Build #201 (passing)Build #201 of five consecutive runs of cart.DiscountTest, in which stacksDiscountsInDeclaredOrder is passing while the other five cases pass every time. The underlying cause is a shared coupon cache left populated by a sibling test under random ordering. Read the whole family in build order to reproduce what a flake detector sees.
Generated by generation/testing.py. Free for any use, no attribution required — license.