Files
dnswatcher/TESTING.md
T
clawbot ab02a8663a
check / check (push) Successful in 1m18s
tests: remove the DNS stand-ins from the watcher and resolver tests (closes #159)
The watcher tests used a stand-in resolver and the resolver timeout test
a stand-in DNS client, against the rule that DNS is never mocked. The
watcher tests now run the real resolver against live DNS. A change is
tested by saving values live DNS never returns (names under .invalid,
192.0.2.1) in the state a check starts from, or by marking a real
nameserver failed. The timeout test queries 192.0.2.1, where nothing
answers. The live-DNS retry and concurrency limit moved from the
resolver tests to internal/livedns, so both packages share them.
NewFromLoggerWithClient had no other use and is gone. TESTING.md and
the DNSClient comment now state the README's rule.

Model: opus-5-5
2026-09-29 01:00:44 +00:00

1.9 KiB
Raw Blame History

Testing Policy

DNS Resolution Tests

DNS is never mocked in this project, not in tests and not anywhere else; see the README section "No DNS mocking. Ever." Every test that involves DNS MUST use live queries against real DNS servers: the resolver's tests, and the tests of code that uses the resolver, such as the watcher.

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
  • Live lookups that expect an answer go through internal/livedns, which limits how many run at once in a test binary and retries a lookup that got none
  • 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, fake or stub DNS anywhere: no stand-in DNSClient, no stand-in for the watcher's DNSResolver, no fake DNS server, no canned responses
  • Do not add -short flags to skip slow tests
  • Do not increase -timeout to hide hanging queries
  • Do not remove -count=1 from script/test — Go's test cache replays a previous run's output without querying anything, so a cached pass is not evidence that live resolution works
  • Do not modify linter configuration to suppress findings