testing: document rules for using TB

[dsymonds]

There's rules about what a TestFoo may do with the *testing.T it is given. Some are documented (e.g. https://golang.org/pkg/testing/#T puts restrictions on invoking Fatalf and friends), but some are not (e.g. Logf and probably most other methods should not be called after TestFoo returns). Same applies to *testing.B and any future such values/types.

I came across this while trying to diagnose a problem that seems to be due to #40908, but realised I couldn't find the rules written down anywhere.

[dsymonds]

Related to #40343, though that one claims that the docs allude to it; however, I can't find the quoted snippet.

[rogpeppe]

Personally, I think most of those rules should be relaxed. We could document that Fatalf just calls runtime.Goexit (and document that it won't actually abort the entire test). We could allow Logf to run after the test has ended (and document that the logged value won't appear if it has).

Having extra rules on the testing infrastructure makes it harder to diagnose the real problems, in my view, and sometimes non-conformance is accidental (for example if a goroutine that's calling Logf happens not to have been shut down properly before the test has completed).

[jamall-mahmoudi-dev]

I think The discussion of some of the testing rules reflects a more general discussion about the relationship between strict and permissive guidelines in software development practice. By allowing some freedom in testing methods, problems can be more easily identified and the principles of clean code and architecture can be maintained without unnecessary restrictions. Both clean code and architecture ultimately help build stable and perfect software systems.