GUIs don't lend themselves to unit testing at all, because the requirements aren't mathematical, but are instead based on human factors.

For GUIs, the proper approach is to unit-test the functionality underneath, not the GUI itself.

Which leads to convoluted architectures just to be able to follow "only write code which there is a failing test for".

How are these convoluted?

After all, any program out there does something. If you know what it's doing, you know what it should do, and what it shouldn't. That means you can test it.

Because given how GUI frameworks are implemented, one needs to add explicit workarounds to follow "only write code for which there is a failing test".

After all, writing the test needs to be possible, to start with.

So adapters, views, commands and what have you need to exist only to fulfill such purpose, and even then, their interactions with the GUI layer don't get tested.

So one is creating them, without knowing if they are the right elements for the GUI layout.

Hence why testing, 100% behind it, TDD not so much.

In my book, the UI isn't part of unit testing - at least, the views aren't. The models and controllers (to use the MVC paradigm) might be, though.