So here is my personal take on UI development- and I'll be the first to admit that what works for me may not work for everyone else.

I have always struggled with UIs because their even driven nature makes them feel very non-deterministic. This is what you guys have been talking about in the last few posts, and it's kind of a point I alluded to in my first post. It's just so hard to think of everything a user can do at any given point in time. Now I'll say, before I go to far, I work on line of business apps, in which we are going to be dealing mostly with CRUD type operations, though obviously with rich a user experience as we can build. So what works for this type of app probably is not a good answer for a CAD type application.

When I first started doing TDD I tried to apply the technique to UIs. Eventually this led me to the previously mentioned MVVM pattern (though I didn't know that's what it was at the time). My feeling at the time was that it was very tedious work to try and test drive a UI, and there didn't seem to be much benefit. This was until I released the code to QA. There was such a noticeable quality difference in what the TDD approach netted me vs my old coding that QA actually told the project manager "whatever is different about the development, make sure they keep doing it".

So I stepped back and took a look at what was different, and essentially it was this: Two side effects of test first development was that I was forced to wrap the "state" information of my UIs into separate classes (which would become "viewmodels") and then handle modifications of this state in very small chunks as I developed (because of the nature of writing small, focused tests). What was happening is that I was FAR more considerate of what any effect any given action might have on the entire state of the viewmodel. So when I had to handle the action "user pushed button x", I had right in front of me all of the potential state changes, and I started writing small tests around what would happen to each one after any given action.

At the end of the day- this just pointed out to me that I was not handling the complexity of UIs well before- and that TDD was forcing me to start writing better code. It was a crutch, in fact. Since then, I believe I have become a better coder of UIs even if I'm forced into a situation where TDD doesn't work because I have developed a better skill at breaking down the effects of total state of any given input a user may perform. Of course, having tests around this kind of stuff is nice as well, but I definitely became better at writing UIs thanks to TDD.

So that's what worked for me- but being as a lot of what I gained through applying unit tests to UIs was a "side effect" of a particular TDD approach and really just an improvement to poor coding on my part, I cannot say that others will get the same quality boost applying TDD, or even unit testing, to UIs.