TDD in non-UI: “Man, this code requires a lot of stubs just to make 1 function call. This API design is bad, I should fix it”.
TDD in UI: “Man, this code requires a lot of stubs, I should fix. Hey Visual Designer, can you… no? Ok. Hey API designer… can you? No… ok.”
This is one reason of many why UI developers like back-end for front-ends. When testing your UI, having to stub 20 http requests + 2 JWT tokens just to show 1 screen is painful. Having just 1 or 3 API’s for a screen is so much easier, and makes your tests less likely to break in the future.
However, while testing can reveal a bad API for your UI, there isn’t much you can do to change the visual UI itself. In my years of doing UI, I’ve had 1 designer slightly change an interaction model because of the difficulty of testing it. (Read: highly unlikely to happen).
If the screen requires lots of data, and has lots of interactions… well it requires it. At that point, your only saving grace is finding ways to re-use your stubs without creating a mess in your tests.