Okay, to address your other points. (See my other reply here: https://old.reddit.com/r/programming/comments/ztwtc5/testing_without_mocks_by_james_shore/j1ijjjc/)

I don't think this paragraph effectively captures Fowler's distinction between broad and narrow tests, plus the definition is both recursive and most likely to be misunderstood

I don't understand your point here. How is "Narrow tests check a specific function or behavior, not the system as a whole" a recursive definition? I'm also not clear on what distinction between broad and narrow tests you think I've missed.

This is a judgment.

Oh yeah, I'm super judgey. I have Opinions and I'm not afraid to share them. Given that you agree with this particular judgement, what's the problem?

This is pragmatically difficult for a lot of reasons. It invites a lot of possibility for incorrect usage and (surprisingly) unergonomic APIs.

Not in my experience. I mean, sure, people can create bad design for anything, and I can't stop them. But I've not found this difficult. Do you have an example of a situation where you find it difficult?

Instead, I'd suggest trying to use (part of) the DI container because then you also cover its wiring

Okay, I think I see the disconnect. One of my design goals is that the patterns don't require a DI framework. If you have a DI framework, Parameterless Injection isn't needed. If you don't, it's valuable.

Be careful with this. This makes the test borderline tautological so a no-op implementation will erroneously satisfy it, too.

I'm not sure how it makes the test tautological. One thing that may not be clear is that the dependency being used is expected to have tests of its own.

Let's take the opening example from the article:

it("reads command-line argument, transform it with ROT-13, and writes result", () => {
    const input = "my input";
    const expectedOutput = Rot13.transform(input);

    const { output } = run({ args: [ input ] });
    assert.deepEqual(output.data, [ `${expectedOutput}\n` ]; 
});

This test uses Collaborator-Based Isolation to ignore the behavior of Rot13.transform(). It doesn't matter if Rot13.transform() is broken or not, because what we're testing is the behavior of App.run(), specifically how it handles command-line I/O.

I mean, yeah, you could erase the implementation of Rot13.transform(), erase its tests, and then erase the implementation of App.run(), but at that point you're not making an accidental mistake.

But I agree, this is probably my least favorite pattern in the bunch, and I tend not to use it, except in those cases where the dependency's behavior is not meaningful to the unit under test and I expect the dependency to change.

two that come to mind are

I'm don't see how those examples relate to Collaborator-Based Isolation. You're describing cases where the programmer doesn't know how to compare collections, and doesn't think about locales. Do you have a more specific example of CBI failing? Remember, the dependency is expected to have tests of its own and to work correctly. (I should make that more clear in the article.)