What an excellent idea! I hope you stick at it. I find the TED talk videos a bit of a mixed bag, so I’m looking forward to seeing your take on them.

All the best,
Ady

Clearly, ‘unit testing’ is now too overloaded to be used without care. I’d say the majority of developers mean ‘mostly single class testing inside a single runtime process’. For people like that, I don’t think there’s a word for testing collaborations of multiple classes, and it’s often seen as a Bad Thing – because it tests too much, apparently – unless it’s called SpringContextTest

There are other kinds of testing which do need to be identifiably separate, and for which it would be nice to have a common vocabulary. I know that because I keep hearing – and being involved in – discussions in which people think they’re talking about the same thing but aren’t. In any reaonsable complex enterprise system comprising multiple deployable components (I know that phrase could do with unpicking, but can we let it ride?) deployment is complex – so it’s useful to be able to test individual deployable components (component testing) and multiple components strung together (integration testing) and of course all components under your control (system testing). Each of these activities is worthwhile, and each has different complexities and pressures, and each happens in general at different parts of the workflow or on different timescales, unless you’re lucky enough to have a blazingly fast continuous delivery ecosystem.

The other dimension, which is more about ‘why’ rather than ‘what’, identifies the primary stakeholder. And there things are equally messy, and there’s equally little shared vocabulary. Here particularly, things have become so confused that the words are nearly useless except as team-specific monikers. I think the most important thing is that a team agree on terminology early on, and be honest about resolving ambiguities.

One starting point involves reflecting on an analogy with taxi driving. I worked on a job which involved taking 2 or 3 taxis a day, and I got to know some of the drivers pretty well. (Many were burnt-out ex-company directors, interestingly.) One of them said to me: “When the traffic was awful, or some idiot was driving like an arse in front of me, I used to get really angry. Then one day I realised that if I carried on this way, I was going to have an early heart attack. The traffic jams, the idiot drivers – they’re just part of the job. Unfortunate though it might be, my job is not to drive at 30 miles an hour through the city – if it was, I’d constantly be thwarted. Instead, it’s to get someone to their destination as soon as possible given all the frustrations over which I have no control and given all the skills I have in minimising constraints over which I do have some influence.”

I find the analogy between software development and taxi driving useful. ‘Legacy’ code isn’t (usually) code written by idiots, any more than most traffic jams are generated by incompetent driving; it’s just code you weren’t involved in writing. And much of the value of a skilled developer lies in their ability to choose safe routes through less than ideal territory – though unlike the taxi driver, we can sometimes build entirely new roads.

And again by analogy: like most drivers, I am a hypocrite. I curse someone for driving too close; then within minutes do the same thing myself. Equally, I’m sure my code is as often the cause of WTF moments as the code I’ve inherited. But just as it behoves drivers to pay attention to the quality of their own driving, I am well aware of the need to minimise the WTF-ness of my own output. Accordingly, I try to make it expressive, testable, etc etc. I know that however good I am at that, though, there will come a time when someone lands on a particular piece of code I’ve written and say “why on earth did you architect things that way?” – and that this may simply be because they haven’t been through the same journey I and the rest of the team have. In other words, all code is legacy – with all that that implies – to those who don’t share the mental model developed by the team who wrote it. Most teams I’ve worked with have done too little to make that mental model readily accessible to those who come after them.