The download tests reach real hosts on the network, so the unit-test gate depends on outbound DNS and on two third parties it does not control.
What they reach
UtilitiesTests/DownloadTests.cs:9 and UtilitiesTests/DownloadAsyncTests.cs:9, :40 fetch https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png.UtilitiesTests/DownloadAsyncTests.cs:24 fetches https://www.google.com.UtilitiesTests/DownloadAsyncTests.cs:68 expects failure from https://thisdoesnotexist123456789.com/file.txt, which relies on that name never resolving.UtilitiesTests/DownloadAsyncTests.cs:81 uses https://httpstat.us/200?sleep=5000 to exercise the timeout path.
Why it is worth changing
A third-party outage, a DNS policy on the runner, or a rate limit reds the gate for a reason unrelated to the change under test, and the 5-second sleep is paid on every run. The negative case is the weakest of the four, because a registered wildcard or a captive-portal resolver turns a name that does not resolve into one that does, and the assertion silently inverts.
The fix is a loopback HTTP server in the test, or an injectable HttpClient handler seam, so success, failure, timeout, and cancellation are all deterministic and offline. The seam is the larger of the two, since it is a public-API decision: ARCHITECTURE.md records Download as reusing a thread-safe Lazy<HttpClient>, so exposing a handler changes what consumers can depend on and belongs in that document in the same change.
Where it came from
Raised by the reviewer on #451 against UtilitiesTests/DownloadAsyncTests.cs:16 and UtilitiesTests/DownloadTests.cs:13. Declined there rather than fixed, because that change normalizes every text file from CRLF to LF and these two files are byte-identical to develop with the carriage returns stripped. Rewriting them inside that diff would bury a behavioral change in the churn that makes the rest of it mechanically verifiable.
The download tests reach real hosts on the network, so the unit-test gate depends on outbound DNS and on two third parties it does not control.
What they reach
UtilitiesTests/DownloadTests.cs:9andUtilitiesTests/DownloadAsyncTests.cs:9,:40fetchhttps://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png.UtilitiesTests/DownloadAsyncTests.cs:24fetcheshttps://www.google.com.UtilitiesTests/DownloadAsyncTests.cs:68expects failure fromhttps://thisdoesnotexist123456789.com/file.txt, which relies on that name never resolving.UtilitiesTests/DownloadAsyncTests.cs:81useshttps://httpstat.us/200?sleep=5000to exercise the timeout path.Why it is worth changing
A third-party outage, a DNS policy on the runner, or a rate limit reds the gate for a reason unrelated to the change under test, and the 5-second sleep is paid on every run. The negative case is the weakest of the four, because a registered wildcard or a captive-portal resolver turns a name that does not resolve into one that does, and the assertion silently inverts.
The fix is a loopback HTTP server in the test, or an injectable
HttpClienthandler seam, so success, failure, timeout, and cancellation are all deterministic and offline. The seam is the larger of the two, since it is a public-API decision:ARCHITECTURE.mdrecordsDownloadas reusing a thread-safeLazy<HttpClient>, so exposing a handler changes what consumers can depend on and belongs in that document in the same change.Where it came from
Raised by the reviewer on #451 against
UtilitiesTests/DownloadAsyncTests.cs:16andUtilitiesTests/DownloadTests.cs:13. Declined there rather than fixed, because that change normalizes every text file from CRLF to LF and these two files are byte-identical todevelopwith the carriage returns stripped. Rewriting them inside that diff would bury a behavioral change in the churn that makes the rest of it mechanically verifiable.