ui and testability: the ant farm, the GOTO statement

I have never been a true aficionado of unit testing; 

• I've seen too many that test implementation and not true functionality and that break even though the underlying code is fine after a refactor
• as a form of "documentation" they aren't particularly easy for a human to read and glean information from (though I admit they are more constrained to be updated along with the code, unlike external documentation)
• when written by the same coder who wrote the code under test, they assuredly won't test much that the coder didn't think of when doing the implementation, and most true small units should - frankly - be "too small to fail".
• when implemented and providing high code coverage, they're sometimes cited to give a false sense of security

But mostly, especially for UI, the bugs I've seen that make it to production all depend on context; they're an emergent property of interacting parts that don't properly understand each other enough to play well; 

• the unexpected format of the response from the server - (oh yeah, the format in the db and endpoint updated 2 sprints ago but we forgot to update the code and the tests!)
• the odd browser incompatibility for a CSS or even Javascript syntax
• the surrounding DOM of the page leaking into the embedded unit and doing odd things
• the text value from the server (or the user input) was much longer than the happy path examples on the designers happy-path mockup and things look weird
• a surprising race condition or other sequence-based context-y problem

None of these issues are particularly amenable to being caught early by the isolated confines of a unit test. (And half of them aren't easy to see if your test runner output is based on a command line and not human inspectable UI.)

When you make up a unit test, it's like you set up a tiny 2 or 3 ant ant farm and carefully observe your ants correctly doing their own thing in those glass walls, and sure, it's important to make sure your ants are basically healthy - but there's only a small chance that that's how you're going to catch the problem with all the ants of the colony ahead of time.

The sweet spots for unit tests are in functional programming: ALL relevant input is known / there is no other reliance context to botch things up, a manipulation of that input  - complex enough to be worth testing! - is performed, and the results can be inspected in their entirety. And one reason why declarative programming for UI has gained so much popularity is that of all styles of UI code it has the highest chances of meeting that criteria... but even then the tools for making a component, faking an interaction with it, and seeing the result are just so-so at best. 

Anyway, I didn't mean this to be quite this long of a ramble - mostly I wanted to set up this quote I snagged in 1998:

"Menu items are the modern programmer's way -- even that of the Java programmer, who is too pure of heart to use pointers -- of putting an obscene number of unpredictable GOTO statements everywhere in his code." -- jhayward@imsa.edu via Usenet's "rec.humor.funny"

 Very old school in both tech and gendered language, but I think about that in the context of UI a lot.