It seems like this is a large amount of novel vocabulary to deal with, and I wonder if it's worth having to teach it to new developers?

Some of it conflicts with pre-existing usage in ways that could be confusing. For example, "nullable" already has a meaning in modern type systems. It would be weird to have a "nullable" object stored in a non-null variable.

I was about to write a comment about "Integrity Tests" (different from integration testing). The article mentions "Narrow Integration Tests" and "Collaborator-Based Isolation" which sound very similar.

I don't have a clear definition of integrity tests and would describe it as verifying the interface (or combined behaviour) of two classes/objects. [It's exceedingly difficult to google.] These tests can mock anything other than the things which are part of the interface being tested. The ones I wrote tended to be meta/generic in nature: e.g. validating that all valid inputs to one produce valid outputs from the pair, or invalid inputs to one call nothing outside of the pair, etc. Some slow integration testing with harder to setup/maintain data can be replaced with faster/simpler integrity tests.

I'd never heard anyone call those "integrity tests" before. I think "contract test" is more common.

Assuming I understood you, that is.

I've been telling everyone to look at Pact to make contract testing easier to organize and maintain and to make it easier to trigger in the other tests in CI when an interface's behavior changes. They haven't offered me a commission yet. ;-)

https://pact.io

I've also done contract testing and integrity tests are different, I'm doing a bad job of trying to describe them. I would say that Contract tests could be considered a subset of integrity testing. I think the difference could be that contract tests (as I've used them) generate unit tests for each side. Integrity tests may treat the pair as a unit and test them, to ensure their combined implementation behaves well.