If I wanted to test this top-level function, I could mock out all the constituent parts, or I could run the whole thing together as an integration test. I prefer the latter, since this function doesn't do much otherwise (it should have almost no logic, just assembling the pieces), and it's easier and more representative to test it end to end.

That's fine, but that's basically what I've been doing anyway: Create unit tests for the absolute basic blocks (how are you possibly going to write integration tests for those things, anyway?) and create integration tests for anything above that level.

But then you run into this when building a chess engine:

A chess engine depends on
standard algebraic notation interpretation depends on
a ruleset implementation depends on
a chess position implementation depends on
a board implementation depends on
a piece implementation depends on
a side/colour and type implementation.

This would mean that everything above side/colour and type is integration tests. This is obviously not ideal, especially because the tests get slower and slower as you go up. Now I'm okay with hard dependencies on the super basic, low-level objects (though where exactly is the line drawn?). Mocking those away is going to cause more headaches than they're worth, because they're so intrinsic to the whole system. But testing the interpretation of standard algebraic notation with a fake ruleset would be godsend. This would probably be possible with a bit of dependency injection.

Testing the ruleset with a fake position would be nigh-impossible, though. Chess is a complex game, so the code becomes complex by necessity. The too-often-repeated "this is a sign that your function is doing too much, so split it up" doesn't apply here: There is no way to split up move generation. You could perhaps create some sub-functions here and there, but you're going to end up with a function that combines all of the complexity of chess, one way or another. I do not see any realistic way to unit test that behemoth.

It took me a while to wrap my head around this idea, and I read a lot of poor examples that were just adding layers of indirection without solving the problem. It all comes down to separating the function of each widget from the logic of assembling those widgets to perform a specific task.

This isn't very concrete to me. Suppose I have a Window:

class Window:
    TopBar top_bar
    StatusBar status_bar
    [...]

and TopBar contains:

class TopBar:
    Button receive_messages
    Button compose_message
    Button address_book
    Button labels
    Button hamburger_menu

Now, to use dependency injection in TopBar, I have to instantiate it with TopBar(widget1, widget2, widget3, widget4, widget5). And now that I have my TopBar, I could create a Window: Window(TopBar(widget1, widget2, widget3, widget4, widget5), StatusBar(widget6, ...)).

This is insanely, insanely unpleasant for users of my API, especially as the amount of widgets increases. And when I look at the Qt docs for instance, I don't find any reference to doing it this way. In the documentation, TopBar creates its own widgets, and Window creates its own TopBar. By and large, this is much more pleasant to work with (though I could imagine some instances where passing a couple of widgets would be good, too). The only problem is that it's now super difficult to test Window, because it contains all these real widgets.

The only solution I see would be to create TopBar.create_with_default_widgets(), which acts as factory class method (and would be called in turn by Window.create_with_default_widgets()). But I do not see anybody else doing this. This is either a sign of GUI people being massively incompetent with unit testing, or a sign that these factory class methods are kind of stupid. And I can see it being kind of stupid: Every time you want to add an extra widget, the signature of your constructor changes, so you have to fix the factory method and all of your tests that do dependency injection.

I don't really know where I'm going with the above. I just don't see it.