Tom Breur
8 June 2014
“TDD is dead!” That’s what
I’ve been reading lately, at least. Software craftsmanship is constantly
evolving (fortunately!), and maybe TDD has become sufficiently “mainstream”
that it’s time to supersede it. I’d like
to think so, but I don’t really think we’re there. At least not yet. And not
any time son, either, if you ask me. But that’s just me.
Besides
TDD, “BDD”, “ATDD”,
and “Specification
by Example” have recently come to the fore. I would argue that what they
share is to begin with the end in
mind. Coding before you test, might well reversed by writing the test before you code. That’s where TDD started.
Over time, the concept of
“test” has expanded from Unit testing (TDD), to testing “fit” of your solution
as a whole. To me that seems like a rather natural evolution, and common sense.
I would certainly like to take it as evidence of how our profession is evolving
and maturing. So if TDD were dead, I’d
like to think because we take it as a given, nowadays.
An important innovation
that has made me reconsider my own practices is to “deploy” specifications. If
you can generate code (“execute specifications”), while all stakeholders share
and embrace the proposed functionality, testing has in fact become an integral
part of development (as it should!). The notion of ordering (do we test first,
or should we code first?) becomes a moot point.
At least as important,
when you build a body of specifications for a growing system (and you make these
specifications executable), they
evolve along with the code base. They record the collective history of what the
system is supposed to do (and not
do). But unless specifications are “human readable” (to you, and anybody else
involved), business stakeholders can hardly be involved in making a system work
‘right’, and be effective. After all,
these are your customers, so you definitely want them in
your team!
No comments:
Post a Comment