Driving on the right side of the code

Test-driven development

7 Elements of Radically Simple OS Migration

Column Perhaps one of the most interesting things about TDD is not the specification-oriented and design-centred role in which testing is employed, but the amount of explanation it requires as a term. And I don't just mean expanding the abbreviation to Test-Driven Development or Test-Driven Design, as opposed to, say, Telecommunications Device for the Deaf (That said, I have heard it mistaken for Top-Down Design.)

One illustration of the problem of explanation can be found in the abstract for the session "Are Your Tests Really Driving Your Development?", run by Nat Pryce and Steve Freeman at the XP Day 2006 conference:

Everybody knows that TDD stands for Test Driven Development. However, people too often concentrate on the words "Test" and "Development" and don't consider what the word "Driven" really implies. For tests to drive development they must do more than just test that code performs its required functionality: they must clearly express that required functionality to the reader. That is, they must be clear specifications of the required functionality. Tests that are not written with their role as specifications in mind can be very confusing to read. The difficulty in understanding what they are testing can greatly reduce the velocity at which a codebase can be changed.

One of the common misinterpretations of TDD is that it is no more than getting developers involved in testing. Developers are responsible for their work, which includes the idea that code is tested at the code level, as opposed to just having it tested indirectly in the software system as a whole. This responsibility defines a foundation on which TDD is built, but it is not itself TDD: there is no sense in which the tests are driving an aspect of development. In a traditional developer-based testing approach, tests are employed to discover defects in code, whereas the emphasis of TDD is that tests are also used for specification and design.

The need for terminology explanation, however, often goes further than just clarifying the distinction between traditional developer-based testing and TDD. Not only do many people stop listening after the first word, they follow through by applying one particular interpretation to that word. They hear test and make assumptions and projections about the whole approach based on a limited understanding of what that word might entail.

Presenting a concept by examining the individual words in its name is effective as pedagogy, as the previous quote demonstrates, but such a literal analysis of a jargon term is hopeless if you are trying to read anything much deeper into a concept — instead of depth, you are likely to end up with an understanding that is at best superficial and at worst just plain wrong.

For another example of misinterpreted jargon, let's consider a related term: Test-First Programming. Historically, the term Test-First Programming predates Test-Driven Development.

Many developers treat them as synonyms, but in practice they have slightly different usage: Test-First Programming is normally used in the context of Extreme Programming and emphasises the practice that code that tests for a behaviour should be written before — as opposed to alongside or after — the code that fulfils the behaviour; Test-Driven Development often refers to a slightly broader set of the practices, often when considered outside the context of Extreme Programming, and although a test-first style may be employed, strictness of timing is emphasised less than the role of tests as a form of feedback. Both terms embody the notion that testing is continuous and integrated with development, rather than separated, or even divorced. The Pragmatic Programmers' tips "Test Early. Test Often. Test Automatically." and "Coding Ain't Done 'Til All the Tests Run" capture the essence.

And yet it is possible to miss all of these clues and connotations to misinterpret the idea of Test-First Programming as writing all of the test code for a module or major subsystem before writing any of the code — in other words, do the tests first. Yes, this would be a naïve interpretation of the practice according to its name, but that doesn't stop people making such literalist interpretations. So, inevitably, a few have tried to pursue this mutated style doggedly and dogmatically in the name of buzzword compliance.

A little embarrassingly, one of the software testing classics, Glenford Myers' The Art of Software Testing, was updated by authors who appeared to use this coarse-grained interpretation as the basis of a whole chapter on Extreme Testing. Claims such as "In XP, you must create the unit tests first, then you create the code to pass the tests" and "All code modules must have unit tests before coding begins" are enough to make you cringe and hanker for the unadulterated first edition.

Endpoint data privacy in the cloud is easier than you think

More from The Register

next story
PEAK LANDFILL: Why tablet gloom is good news for Windows users
Sinofsky's hybrid strategy looks dafter than ever
Leaked Windows Phone 8.1 Update specs tease details of Nokia's next mobes
New screen sizes, dual SIMs, voice over LTE, and more
POW! Apple smites Macbook Air EFI firmware update borkage
Fruity firm provides digital balm for furious fanbois
Fiendishly complex password app extension ships for iOS 8
Just slip it in, won't hurt a bit, 1Password makers urge devs
Mozilla keeps its Beard, hopes anti-gay marriage troubles are now over
Plenty on new CEO's todo list – starting with Firefox's slipping grasp
Apple: We'll unleash OS X Yosemite beta on the MASSES on 24 July
Starting today, regular fanbois will be guinea pigs, it tells Reg
Another day, another Firefox: Version 31 is upon us ALREADY
Web devs, Mozilla really wants you to like this one
Secure microkernel that uses maths to be 'bug free' goes open source
Hacker-repelling, drone-protecting code will soon be yours to tweak as you see fit
prev story


7 Elements of Radically Simple OS Migration
Avoid the typical headaches of OS migration during your next project by learning about 7 elements of radically simple OS migration.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Consolidation: The Foundation for IT Business Transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.
Solving today's distributed Big Data backup challenges
Enable IT efficiency and allow a firm to access and reuse corporate information for competitive advantage, ultimately changing business outcomes.
A new approach to endpoint data protection
What is the best way to ensure comprehensive visibility, management, and control of information on both company-owned and employee-owned devices?