The disk is lava: generate your test certs in memory
You can't out-engineer the speed of light, only avoid the distance. Grace Hopper, the computing pioneer, made that physical: she handed people a length of wire and called it a nanosecond, about thirty centimeters, the distance light travels in a billionth of a second. A microsecond was three hundred meters of it. Generating a certificate is about twenty kilometers of that wire; reading one off disk is sixty; fetching it from network storage is hundreds. Same units, very different trips. A test that reads a cert from disk takes the long one, and committed a private key to your repo to do it. Generate it instead.
You're not testing the standard library
When a test needs a TLS cert it's tempting to treat it as precious and check it
in. But you're almost never testing "does P-256 signing work" or "is the
handshake correct": you trust crypto/tls and crypto/x509 for that, the same
way you trust the compiler. You're testing your logic: that your option
builder wires the cert into the transport, that your chain verification accepts
a good chain and rejects a broken one, that your load-cert-from-a-path API reads
the file.