I was lucky enough today to sit down with a solutions architect who walked me through a simple
test-driven development (TDD) and behavior-driven development (BDD) exercise.
My mind was blown. It was everything he said it would be: it's challenging, because you have
to think differently about the problems you're solving — first and foremost, you have to partition
your mind to focus only on the test — it's givens and the outcome you're looking for (this is the
test-driven part) — and
THEN to focus on writing the code to satisfy the outcome (this is the behavior-driven part).
The net result is amazing and mind-bending. By making yourself think in this way,
the code is reduced to the means of satisfying the tests. In that sense, it is pure.
I've worked for several organizations that all said they wanted to move to TDD,
but couldn't. One reason: clients didn't want to pay for it. TDD pushes out the time
to produce an application, but the benefit is the code doesn't fail. Add to that a
continuous integration server that runs your tests and re-runs them when others
check in their test-driven code...
I guess I want these guys to understand how lucky they are that they actually
get to engineer in this way. I think it's super amazing. I'm SO grateful for the demo
I received today.
|