docs: TESTING.md constraints match the resolver and the test-time policy (closes #289)
check / check (push) Canceled after 0s

The Constraints list named a query timeout calibrated to round-trip time and a
limited root-server fan-out; the resolver has neither. It now gives the
2-second timeout and the second try over UDP, says a zone's servers are asked
one at a time in a random order, and gives the 60-second cap and 20-second
target for make test from REPO_POLICIES.md. The line on flaky failures now
says, as the README does, that a flaky live test is fixed with robustness,
never with mocks or skip flags.

Model: opus-5-5
This commit was merged in pull request #292.
This commit is contained in:
2026-10-15 18:01:51 +02:00
parent db3b09c5d8
commit f6b7aefcbf
2 changed files with 13 additions and 7 deletions
+9 -7
View File
@@ -19,16 +19,18 @@ works correctly in production.
### Constraints ### Constraints
- Tests hit real DNS infrastructure and require network access - Tests hit real DNS infrastructure and require network access
- Test duration depends on network conditions; timeout tuning keeps the suite - Test duration depends on network conditions. `make test` must finish in under
within the 60-second target 60 seconds, the hard cap in `REPO_POLICIES.md`; under 20 seconds is the target
- Query timeout is calibrated to 3× maximum antipodal RTT (~300ms) plus - Each query to a nameserver has a 2-second timeout, and a query over UDP that
processing margin gets no reply is sent once more (`queryTimeoutDuration` and `maxRetries` in
- Root server fan-out is limited to reduce parallel query load `internal/resolver/iterative.go`)
- In the walk to a name's nameservers, the servers of each zone are asked one at
a time in a random order, as the README's DNS Resolution Strategy describes
- Live lookups that expect an answer go through `internal/livednstest`, which - Live lookups that expect an answer go through `internal/livednstest`, which
limits how many run at once in a test binary and retries a lookup that got limits how many run at once in a test binary and retries a lookup that got
none none
- Flaky failures from transient network issues are acceptable and should be - A flaky live test is a robustness problem, fixed with retries with backoff,
investigated as potential resolver bugs, not papered over with mocks or skip several independent nameservers or longer timeouts, never with mocks or skip
flags flags
### What NOT to do ### What NOT to do
+4
View File
@@ -19,6 +19,10 @@ milestone: https://git.eeqj.de/sneak/dnswatcher/milestone/7
# Completed Steps # Completed Steps
- 2026-10-15: `TESTING.md` Constraints give the resolver's 2-second query
timeout and second try, say a zone's servers are asked one at a time in a
random order, give the 60-second cap and 20-second target for `make test`, and
say a flaky live test is fixed with robustness, not with mocks (closes #289).
- 2026-10-15: a request under `/s/` that names a directory, such as `/s/` or - 2026-10-15: a request under `/s/` that names a directory, such as `/s/` or
`/s/css`, answers 404 instead of a listing of its files (closes #286). `/s/css`, answers 404 instead of a listing of its files (closes #286).
- 2026-10-15: a notification endpoint that answers with a redirect, or any - 2026-10-15: a notification endpoint that answers with a redirect, or any