Thread by @GeePawHill

TDD pro-tip #3: remember who works for who, and shape your tools to your hand, not your hand to your tools.

(btw, these tips are in no particular order. if you want to know the truth, i'm musing them as i do them. people always know more than they can say, and i'm no exception, but i'm digging at what i do over and over, and sharing it.)

one difference i see over and over between noobs and olbs is the amount of time that olbs invest in making their environment -- software tools & source-base & hardware alike -- do exactly what they want.

let's call all of that, the s/w, the h/w, the test-base, the shipping-base, the whole thing, let's call it the environment.

olbs, then, feel that the environment works for them. when an aspect of the environment is annoying, olbs stop what they're doing and change the environment until it isn't annoying. noobs don't do this with that kind of authority and confidence.

two sketches for examples, both test-related, one simple and one mega, both of which i have/am doing on my current gig.

the simple sketch: the code that correctly ascertains that two modest tree-shaped structures are identical is about six lines long. i need to ascertain that across quite a few tests.

as soon as i get it working the first time, i see that it's quite generic except for the two structures to be compared and one extra parameter that guides part of their comparison. but those three args are embedded in non-obvious places in that six-line snippet.

without even thinking about it, i extract that six-line snippet into a method parameterized by the three arguments. why do i do that? it's because that code works for me, and i find it hard to grasp quickly in its native state.

if i worked for the code, i'd blame me. y u so stupid & ugly u can't quickly pick out the three important differences between these six lines and those six lines?

but the code works for me. if i have a problem, *the code* has to change, not vice-versa.

here, the code is the environment. sometimes it's the tools. i was working perl not long ago -- the '80s yet live -- and the test facility there is procedural, verbose, and doesn't take complete perfect control. so what did i do? took a couple of days and improved it.

that tool works for me, and i use it every day all day long. i'll give it a little while to see if the blisters on my hand are just a toughening thing. but if they're not, the tool suffers. i don't suffer.

a mega sketch, then. a great many of us work with complex databases with dozens of interlinked tables, fronted to us via service calls. (true of most modern web-ish dev, but also of much modern backend dev.)

like many of us, the base of my environment is just such a beast, where my code is downstream of a whole ton of "not-my-code" data suppliers.

the keys: 1) the upstreams are slow, sometimes unstable, & contain massive amounts of data. 2) my app uses the upstreams mostly opaquely, indifferent to actual content. 3) even when the upstream values are actively used, i need only dribbles of it to prove my code works.

so? i build my code so that those upstreams are the barest thinnest interface, and i back that interface with two versions, live and dead.

the live version really does call the database or the service. it really gets whatever random shit is in there. it really reads thousands and thousands of items.

the dead version contains a hand-rolled dataset that is miniscule, expressed in code in a DSL, using prototypes (builder), and has just enough in it to demonstrate every variant i need to deal with.

and i hear you thinking: he's talking about a fake, a test double, a mock.

on the one hand, i'm glad your mind went there so quickly, it proves you're paying attention. on the other hand, you're mistaken.

that hand-rolled rigged dataset is in the shipping code, with a feature-toggle that tells the app whether to use it or not. it's not testing code. (i do *use* it sometimes in the testbase, but the shipping base depends on it.)

why would i do that? because in actual TDD as opposed to toy TDD, i am solving problems i have never solved before. i don't have a testing framework that lets me poke at them -- yet.

i need to run the whole app dozens of times a day to find my way in to that code. a lot of it is stuff i will never bother to test. once the layout pleases me aethetically, both in the code and on the screen, i will never lock it down using tests.

some of that work i'd like to test, but as i say, i have no idea yet how to do so. i need to run the app to get clues, and i need to run the app to back up my refactoring-to-testability push.

(and some? some of that work i will never figure out how to test in a way that is efficient and effective. in javafx, there are acceptance-test frameworks galore, but they're neither efficient nor effective.)

the point is, i need to run the app dozens, hundreds, of times every day. and with unstable, slow, and gigantic upstreams, doing that is hell.

guess what, tho. i don't work for the code. the code works for me. investing a few days to get the dead datasets working will save me and other, future, devs thousands of hours of just sitting there waiting to see what happens.

(short break, need to run to the store. i'll come back and wrap this in a little bit.)

we've mostly seen the money premise and the steering premise, and they're certainly being invoked here. it's a waste of money for me to sit and watch a slow-loading or unstable upstream, that's the money premise.

and the steering premise says we change designs for testability -- but note that here the testability i want isn't micro-testability, it's human-testability. i want to run the app a whole bunch to figure out what i want, not a part of the app to prove it does what i want.

and how/when do i decide enough is enough, and that the tool has to change shapes because my hand isn't gonna change shapes? ahhh, well. we encounter the judgment premise.

the judgment premise: in writing software we are permanently, ineluctably, irremediably, irrevocably, and *happily* dependent on individual developers using their individual judgment.

the activity i'm talking about here, remembering who works for who, and to shape the tool to the hand and not the hand to the tool, is absolutely *riddled* with me making complex nuanced judgments.

i sometimes put it another way: "become sullen and resentful when something doesn't work well for you." what i'm saying there is that your discomfort and what you do about it is an absolutely central topic in mastering geekery.