Tuesday, May 10, 2011

Test Driven Development: by Example

On the way back home Sunday, I also read most of Test Driven
by Kent Beck, who is an author I have heard referenced alot
but never read.

Good quote: "Every programming practice encodes a value system,
explicitly of implicitly"

--Kent Beck

I used a fair bit of TDD on the mail server project, as well as
conformance testing, system testing, stress testing, and a dash of
regression testing. The SMTP protocol logic especially was developed
incrementally and test first.

The book was alright, the first step-by-step example was
a little wandering but eventually enlightening. I actually liked the
end of the book more, where he gives a large review of test patterns, as
well as design patterns and refactorings as applied to TDD.

One of the sections I enjoyed most was "How do you know if you have good
tests?". For me, one of the greatest benefits of TDD isn't that you
are left with tons of test artifacts that you can use for verification,
refactoring, or maintenance. It's that you can continually,
incrementally, and easily fire up and exercise your code base in little

In this section, Kent Beck points out that bad tests can be an
indication of bad design in the production code. If you can't get your
code in a test hardness because of external dependencies of filesystems,
servers, or databases, it isn't the fault of unit-testing as a
discipline; your production code has too many dependencies. Similarly
if you feel you are instantiating 2/3rds of your code base to run one
object. Because unit tests exercise chunks of the codebase separately,
they verify that you really do have a modular design, and provide alot
of motivation to extract interfaces and encapsulted complicated and
concrete implementations.

This spat of reading on software engineering has really gotten me to
thinking about how to backport these techniques to languages less
focused on encapsulation and dynamic polymorphism (read: C). I might do
a series on modern and modular design techniques in plain-old C. It'd
be stuff most professional developers probably know about, but that
wouldn't show up in K&R.

No comments:

Post a Comment