How BitSpeed Inspect and Transfer Were Tested

Each tool makes one main promise, and the tests go after that promise first. Inspect promises to explain where observed request time went without inventing a cause. Transfer promises that an interrupted file transfer resumes from verified pieces and ends in one complete, checked file. Happy paths are covered too. They just aren’t where the effort went.

Every push to main runs the full suite on Linux and macOS: formatting, go vet, race-enabled tests, both command builds and smoke checks against the built executables. The outcomes are written to recorded results with the Go version, platform and a fingerprint of the source tree.

Inspect tests target timing attribution and comparison verdicts. Transfer tests target integrity under process kills, corrupt chunks and storage failures.

Inspect

Controlled local endpoints delay headers, stream slow bodies, redirect, return empty responses, disconnect early and stall until a timeout. A report that only handles a clean request would miss half the job. The tests check timing arithmetic, events that never arrived, partial observations, links from every interpretation back to its evidence, and redaction of query values in saved URLs.

Comparison tests try to trick the verdict. Changed payloads and encodings, mixed failures, zero baselines, too few samples and overlapping ranges all have to narrow the conclusion instead of producing a confident “faster”. The Inspect case study shows that rule at work on saved recordings.

Transfer

Transfer is tested by killing it. Executable checks stop the real sender and receiver with SIGKILL at three points: in the middle of a chunk, after a chunk is stored but before the reply arrives, and after the file is published but before the final reply arrives. Each run restarts both processes with the same snapshot and ID and must end with one verified destination file and a stable receipt. A lost final reply must not produce a second file.

Lower down, the tests feed in wrong chunk lengths and hashes, malformed manifests, refused tokens, storage limits, damaged stored chunks and injected disk write and sync failures. Progress the receiver can’t prove is never reported as verified. A packaged TLS listener is checked with a trusted local certificate. The Transfer case study walks through one killed run with the released binary.

Releases and platforms

Release automation builds Linux amd64 and arm64, macOS amd64 and arm64, and Windows amd64 archives, then runs the packaged executables natively where it can. Inspect runs its record, explain and compare checks on Linux amd64, macOS arm64 and Windows amd64. Transfer runs delivery, interruption and TLS checks on Linux amd64 and macOS arm64. Linux arm64 and macOS amd64 are cross-built only. On Windows, Transfer checks version, help and the refusal of unsupported operations, and it doesn’t deliver files.

After each release went public, every archive was checked against SHA256SUMS at both the tagged and the stable download address. The evidence sits in Inspect 0.1.1 release results and Transfer 0.1.0 release results.

Process kills and injected failures support the documented persistence sequence. They don’t prove how every disk behaves when the power goes out. The Transfer coverage reference lists exactly what was and wasn’t run.