from my stuff about five underplayed premises of TDD, (here: geepawhill.org/five-underplay… ), i have a real-world experience and rant about ignoring the steering premise.
the steering premise says that tests & testability are first class participants in design. it means that an untestable design basically just isn't a viable design, any more than, say, a design that produces random results for a deterministic process, or any other design bug.
the world of libraries and frameworks is of course chock-a-block with designs that were built by people who don't do TDD or honor the steering premise.
one such is javafx, the GUI framework used by modern java desktop apps.
like all UI frameworks, the javafx gui is single-threaded. like all UI frameworks, when you do long-running -- i.e. thread-blocking -- work, you have to do it on a worker. like all UI frameworks, you have to pass partial/intermediate results across threads. so far so good.
the mechanism for doing this in javafx is to have your worker call Platform.runLater with a lambda (or anonymous inner or whatever). the UI thread will then do that work on its own thread "when i get around to it". this is complex but also bog standard. there's no other way.
(that's a lie: one *could* have the UI thread poll, but that's considered old-school. having UI threads spend cycles asking workers how it's going sounds simpler but actually isn't.)
this all works more or less as expected. problem: i want to test that my worker is in fact providing partial results correctly. (or for instance that it cancels correctly, etc.)
because no one at oracle considered testability a first-class participant, there is no sanctioned method to say "wait for the runLater queue to be emptied".
to test such a thing, one *must* either have a very fast worker or have a sleep. both choices absolutely suck. 1) the whole point of workers is that some are not very fast. that's why they're workers. 2) sleeps are either inefficient or introduce intermittent timing errors.
all that would be needed would be the ability to say "waitForRunLater(timeout)" which would return timeout millis after the runlater queue was empty.
now why didn't they do that? simple: because there is no possible valid use for this in a *shipping* environment. the only valid use would be in a *testing* situation. and testability has never been a first class citizen in oracle's designs.
it is very frustrating to work with libraries and frameworks that prevent natural testability. my current gig involves a fairly complex worker-updating system. i have spent days debugging that system, and now spend time debugging tests that worked fine before the threading.
