I could write a response, and one day I will post about this, but this video addresses your points very well https://youtu.be/ln4WnxX-wrw.

I will say, though, that when I write the type of low-level code you’re asking about, I tend to centralize it so there’s only ever one piece of the software that knows about it, and then that piece will be mocked.

If I did need to have addListener called some place, I’d actually have three components with their own tests— one that the destination component calls thisFunctionIWasGiven with the correct arguments in the correct situation, one that the builder or parent component provides thisFunctionIWasGiven in the right circumstances with the right arguments, and the dispatcher itself, with tests that it does what it should with the queue.

If your dispatcher needs to change internally how it deals with the queue, that does not matter to either the builder/parent or the destination. Similarly, if you need something else to happen as a result of thisFunctionIwasGiven, that change is isolated in the provider/parent. If you need to change when you call thisFunctionIWasGiven, that change is isolated to the destination component. The builder/parent component may have a hard dependency on the destination component, depending on what else is going on in your architecture, but in many languages it’s kind of a given that parents at least have to know what their children are enough to set them up. So that would mean that you couldn’t write the builder/parent and its tests without first having the child and its tests.

TDD encourages leaf->trunk building for this reason. That does mean that, yes, you have to plan out at least enough of your design to know what some of the leaves are likely to look like before you start.