Hey Folks! It’s a new site. If you see bad links or odd behavior, please contact me right away. Thanks! – GeePaw
 Home  Home  hom  Meet with GeePaw  Meet with GeePaw  mee  Work with GeePaw  Work with GeePaw  wor  Who's GeePaw  Who's GeePaw  who  Blog  Blog  blo  Contact  Contact  con

Five Underplayed Premises of TDD

 15. August 2017

(For an update, with video and transcript: try here.)

here are five underplayed premises of TDD.

why “underplayed”? well, they’re there. hardcore TDD’ers model them all the time. but it feels like they just don’t get the camera time. i want TDD coaches and teachers to step back from “what’s an assert” and rigid rule systems, and highlight these premises in their own work.

the money premise: we are in this for the money. that’s a funny way to say it, on purpose, but here’s what i mean.

i use TDD for one reason and one reason only: to move features faster. more faster features is my job. TDD does that. in particular, here are some substitute reasons to do TDD that aren’t nearly as spot-on. i don’t TDD for art. i don’t TDD for intellectual purity. i don’t TDD for morality or good citizenship, or even quality.

when i write tests, i do it because writing tests lets me make more features faster. that’s the only reason. when i don’t write them, it’s cause writing them – for some case – does not make more features faster.

the judgment premise: there’s no computable algorithm for rolling code well. geeks doing TDD use individual human judgment, all the time. we use our judgment to decide when to write a test, or not. when to write a faster one, or not. how to ‘joint’ a problem testably, and so onflowcharts of TDD are training wheels at best. they leave out parts of what i do because they must – i’m a TDD’er, not a TDD algorithm. we are permanently, absolutely, irremediably, – and happily – dependent on your individual human judgment as a TDD’er.

the chain premise: the best way to test a chain is to test it link by link. this premise underlies our huge preference for testing very tiny subsystems of our larger app. if a function involves a chain of objects, A -> B -> C -> D, and we satisfy ourselves, Aworks if B works. B works if C works, and so on, we have come very close to satisfying ourselves that ABCD works.

i can hear the yabbits blowing in the warm spring breeze. please read carefully: very close. why is very close so good? because single-link tests are orders of magnitude easier to read, scan, write, and run than larger-scale. and remember: i’m in this for the money. those cycles i don’t spend reading et al large-scale tests are cycles i use to move more features.

the chain premise is about a preference, not a rule. i often test subsystems, or even through subsystems, but the chain premise pushes me towards the smallest and lightest subsystems that will prove the point.

the correlation premise: the internal quality of my code correlates directly with the productivity of my work. we could say a lot about external quality (EQ) vs internal, (IQ), but i’ll shorthand it here. EQ is things detectable by an end user. IQ is things detectable only by a programmer with the source.

the correlation premise is hard for some folks cuz they confuse those, EQ and IQ. here’s the thing, you can trade EQ for more features faster. you can. if my customer doesn’t care if it’s slow, i’ll finish faster. if she doesn’t care that it’s ugly, i’ll finish faster, doesn’t care that the program’s rules don’t map perfectly onto the domain’s, same.

consider the polynomial of my daily productivity. two big terms are 1) my skill, and 2) the domain’s complexity. if i hold my skill and domain complexity, what’s the next biggest term, the one that dominates my production function? it’s the quality of the material i start with. this is the correlation premise doing its work.

finally, the driving premise. tests and testability are first-class participants in design. when we sketch designs, we consider many 1st-class factors. the two non-TDDer’s and noobs focus on: ‘will it work’ and ‘will it be fast’. but the driving premise says the third first-class question is ‘will it test’.

tests & testability considerations shape our code. the biggest block i’ve seen in young’uns getting to TDD is their unwillingness to change designs to make them readily testable. the driving premise says we have to. there’s a tangent i’ll offer, maybe later today, on soft-TDD vs hard-TDD, but either way, we have to.

so those five premises underlay almost every move a TDD’er makes. and this is all pretty flavor-agnostic. it cuts across schools pretty well.

we’re in this for the money. we rely on human judgment. we tests chains link by link. we keep IQ high. we shape design w/testability.

my coaching and teaching friends, if you’re out there doing your thing today, please talk to folks about the premises you’re using. we absolutely have to get past this thing of creating faux-systems of rules, and in to transferring the heart of TDD.