if u think the semaphore mechanism in your library works, then test to the level of setting the semaphore. if u think it *doesn’t* work, then u need another library or o/s. testing across threads is for people who are testing semaphores.
if u think that your JSON transport works — from your UI’s perspective or your backend’s perspective, then test to the level of feeding it JSON. if u think it *doesn’t* work, then u need another library. testing across JSON transfer is for people who are testing JSON libraries.
if u think SQL works, then test to the level of emitting SQL or logic’ing recordset values. if u think it *doesnt’* work, then idunno even what u should do. testing across SQL lines is for people who write SQL libraries.
i could belabor this, but i feel i’ve done enough listing of the pattern.
sometimes my simple string manipulation creates bad output. the odds are 10,000 to 1 at least that that is because the *billions* of users of that library haven’t found the lurking substring bug. nope. far more likely, i just screwed up on my end.
play the odds.
the money premise says we’re in this to “ship more value faster”. we are not in this, unless we’re the authors of said libraries, to prove that semaphores, SQL execution, JSON transmission, or strings, work correctly. pro-tip: they generally do. now, let me head the yabbit chorus off at the pass: are there library bugs? oh, hell yeah. to cite a well-known case, the c++ STL shipped for *years* with operations that were thought to be thread-safe but weren’t. (look up the “rope” class.)
but when my string manipulation goes south, i don’t *start* with the silicon, the cpu, the language, or the library. i start with what i typed. this is a hard call for juniors. 1) they’re still thinking that the purpose of tests is to prove that all things are meet & just. 2) they don’t really know how their string library works at all.
1) nothing proves that all things are meet & just, nothing. not one thing. nothing. nope nope nope.
2) there are a variety of techniques for learning how library X works, and you should try whichever ones will help you. i know my string library, but i quite often write tests just to see if i’ve invoked something (a little less common than string) correctly.
i use tests for this cuz it’s a handy way to probe something: u get to invoke a toy situation to understand how the library will behave when u use it for real. but that’s just convenient in context. i usually toss those once i get it. those tests are useful for me to run. they *might* be useful for me to keep, if the library is a little unstable or my learning is still wobbly. but they’re not the point of TDD.
i use TDD not to establish that all the things in my program are meet & just, and not to establish that, say, semaphores work. i use it to establish that what i *said* is what the computer *heard* is what i *meant*. and if u think that is a very low bar, then i suggest that you’re either not a working geek, or you’re young, dumb, and full of memory, and convinced that your capacity is infinite. i’ve encountered many folks of both stripes.
making sure that what u *said* is what the computer *heard* is what u *meant* is, in fact, the hardest part of professional programming for the first X (3? 7?) years. it eventually transforms in to design, where the hardest part is breaking non-toy problems into toy problems.
i am prepared, in the fullness of time, to discover that 90% of my programming failures come from other source than just the trivial breakdown of one of those two links, said -> heard -> meant, from me to the ‘puter. i would like *so* *much* for something else to be at fault. i would love it if every complain logged against my code was because a) i didn’t understand what was wanted by the customer, or b) the customer-interpreters i work with are vague and somewhat mentally less capable.
sadly, that’s not my *main* problem. my main problem is that the code doesn’t do what *i* thought it did, regardless of whether it does what i was told it should do or whether what i was told it should do is what the buyer actually wants or needs. i know such problems exist. of course they do. but they are of a higher order. it doesn’t matter that it isn’t what i was told or that it isn’t any good for the market if it does not do what i want it to do.
TDD proves to *my* satisfaction that *my* code does what *i* think it does. proving that is just prima facie evidence of awesomeness, but disproving that makes all other links in the chain irrelevant.