Only Test if it Brings Value
I don't test typically, but if I did I certainly wouldn't aim for any percentage number of coverage or loading tests in front of everything I wrote but rather focus on handling of things I don't control and things that were coded poorly that I don't have time to rewrite.
If behavior of things I do control and that I did in fact write is unpredictable, my problem isn't that I don't have tests, it's that I wrote piss-poor code that will be ungainly and a beast to maintain regardless of how soon I find out that it's acting up (which is usually right away on the client-side if you haven't allowed it to be overwhelmed by pointless complexity). You only get so much time and UI tends to involve too many factors to attempt to micromanage the process of writing it successfully with something like a test-first TDD approach. I prefer a focus on keeping the code clean, obvious, minimal and robust.
Bury the DOM
IMO, the key to discovering things that are within reason to test is to bury all the client-side stuff in objects that can be manipulated more at an app-level of architecture. The goal being that at the highest level - so implementation and re-usable code typically - you just have plain vanilla objects. You're not looking at ajax methods being fed large sets of options and $ and document.getViaRidiculouslyExplicitlyNamedMethod, You're looking at stuff like comboFactory.build('combo_class_name') that any server-side dev that was mostly clueless about the client-side could figure out how to use.
What this does for you is split minutiae of the DOM-related stuff where keeping things robust isn't as simple as loading tests in front of every little thing you write, from the more app-level data flow concerns that you can actually think of in terms of a flow chart. That's where I would focus testing efforts if I wanted them.
So in the case of your crazy dynamic form:
If your ajax is all bundled up into service objects or a part of some silly seamless data layer that hides the async communication factor completely, you don't need to test in the context of the form. Service calls work or they don't. They can be tested independently.
For the dynamically populated form inputs, The vast majority of these inputs load from one other thing getting set. I wouldn't consider something like that worth testing as it's more likely to break due to DOM shenanigans tied to CSS or an HTML if your services already check out. So, maybe Selenium at the most. but unit tests don't really make sense to me there. Test-first-TDD never made sense to me but especially not for something like that.
Thoughtful Architecture First
If we have an ultra-complicated form with inputs populating themselves and mutating based on all 20 other input states in that form, assuming I had no power to call for a redesign (which would typically be the real problem in that case), I would go with a data-bound event-driven approach such that each input manipulation alters one set of data, triggering events on the data object itself that might cause other portions of your data model to mutate but the inputs themselves at most set the piece of data they care about and listen for changes to that set of data resulting in at most a handful of different types of behavior.
For each input, that's two simple avenues with minimal branching that work or don't work and we're not likely to change in a way where potential fail-points aren't obvious and it's easy to hand test thoroughly before committing. That keeps the spider web of relationships confined to whatever your data abstraction is, narrowing all the more uncertain stuff down to something that itself only cares about what's left when other data elements get altered.
The question is what you value most, what I've just described or something a little bit more tangled and confusing but with tests all over it. My opinion is fairly strongly weighted on the former, but if you can manage both, power to you.
In UI, the DRY principle is paramount, IMO. Don't add tests unless there's a good argument that they'll add value over more time spent carefully crafting a code base in the first place such that it's easy to read, easy to modify, and easy to re-use portions of elsewhere. All three of those things require a number of other widely acknowledged critical heuristics in the craft of coding for which there is no substitute in my experience. Those are what drive my architecture and as a result it's not hard to add tests most of the time if I want to but I would never let a testing strategy actually drive my architecture. I'm only just starting to become more of a generalist but I'm fairly convinced at this point that these priorities work well for more than just web UI.
