sneak
9cb2c2b7e0
All checks were successful
check / check (push) Successful in 1m18s
The resolver's live-DNS tests failed nondeterministically, a different subset each run. Three structural causes, all test-side: - Burst fan-out. Every test in the package is parallel and the build hosts have many cores, so all ~35 iterative resolutions started at the same instant and, because queryServers walks rootServerList() in fixed order, hit the same root server within milliseconds. Root servers rate-limit that. - No retry anywhere. One dropped UDP packet in a delegation chain failed a test outright. - Unanimity assertions. TestQueryAllNameservers_AllReturnOK and _NXDomainFromAllNS required every one of a domain's nameservers to answer, with no tolerance for one being slow. New internal/resolver/livedns_test.go addresses each: a package-wide gate bounds how many live resolutions are in flight at once, every live operation gets three attempts with exponential backoff and its own deadline, and multi-nameserver assertions now need a strict majority rather than unanimity. The retry predicate is deliberately transport-level -- "did a nameserver answer at all" -- never the assertion under test, so a resolver that answers incorrectly still fails on the first attempt. A nameserver that stays silent is tolerated; one that answers wrongly is not. livedns_harness_test.go tests that machinery directly: quorum arithmetic, status counting, the gate's concurrency bound, per-attempt deadlines, and recovery from a transient failure. It touches no DNS. Nothing is mocked, faked, stubbed, recorded, skipped or build-tagged, and production resolver behaviour is unchanged. Test caps move to the new org-wide values ruled at prompts issue 41: 60s hard cap, 20s target, 90s -timeout backstop. REPO_POLICIES.md is re-vendored byte-identical from sneak/prompts rather than hand-edited, which also picks up the golangci-lint paragraph this copy had drifted behind on. TESTING.md's stale 30-second target follows to 60. #93
35 lines
1.3 KiB
Markdown
35 lines
1.3 KiB
Markdown
# Testing Policy
|
||
|
||
## DNS Resolution Tests
|
||
|
||
All resolver tests **MUST** use live queries against real DNS servers.
|
||
No mocking of the DNS client layer is permitted.
|
||
|
||
### Rationale
|
||
|
||
The resolver performs iterative resolution from root nameservers through
|
||
the full delegation chain. Mocked responses cannot faithfully represent
|
||
the variety of real-world DNS behavior (truncation, referrals, glue
|
||
records, DNSSEC, varied response times, EDNS, etc.). Testing against
|
||
real servers ensures the resolver works correctly in production.
|
||
|
||
### Constraints
|
||
|
||
- Tests hit real DNS infrastructure and require network access
|
||
- Test duration depends on network conditions; timeout tuning keeps
|
||
the suite within the 60-second target
|
||
- Query timeout is calibrated to 3× maximum antipodal RTT (~300ms)
|
||
plus processing margin
|
||
- Root server fan-out is limited to reduce parallel query load
|
||
- Flaky failures from transient network issues are acceptable and
|
||
should be investigated as potential resolver bugs, not papered over
|
||
with mocks or skip flags
|
||
|
||
### What NOT to do
|
||
|
||
- **Do not mock `DNSClient`** for resolver tests (the mock constructor
|
||
exists for unit-testing other packages that consume the resolver)
|
||
- **Do not add `-short` flags** to skip slow tests
|
||
- **Do not increase `-timeout`** to hide hanging queries
|
||
- **Do not modify linter configuration** to suppress findings
|