← Back to team overview

elementary-dev-community team mailing list archive

Test Driven Development

 

Hello everyone,

I'm just leaving San Jose after having spent a week listening to a lot of
smart people talk about, among other things, Test Driven Development (TDD).
I know I keep harping on this, but among the people who write the coolest,
best software (and other average software folks) TDD is seen as absolutely
critical. I can't point to anything other discipline in the software world
that is of comparable importance. And here's why:

When we start writing software, we can manage it with a couple of
developers, perhaps all the way up through the first release; however, as
we add features, our software becomes more complex. It's hard for us to
remember what parts of our programs worked well before and what parts are
broken. We often make changes to the underlying architecture to facilitate
a new feature, but we're not exactly sure if in doing so, we broke an
existing feature. And we'll of course do a little ad hoc manual testing to
verify that things still work, but we're only going to really check 5-10%
of the code that we most suspect would break. And even if we do power
through, we're only going to ever check 60-70% of the code, and it's all a
very slow, unreliable process. Soon we spend all of our time fighting bugs
and we can never get around to any interesting work. Does this pattern
sound familiar?

With TDD, you write a simple, small test for every piece of interesting
code you write, and every time you rebuild the project, all of your old
tests run. If you're writing good tests, you can be assured that all of
your code works as you intend it to every single time you build, and if
someone merges in a bug, it will be caught immediately (and the test that
fails will give you some good information about what broke/where the bug is
hiding).

Of course, it takes time to write tests; however, it's still much less time
than you would spend debugging your code. Furthermore, when you write tests
before you write your production code, you are forced to design your code
modularly just to make it testable. Among software professionals, TDD is
seen as *the fastest way to write software*. I mean, Luna has been 90%
complete for 90% of its development cycle, and this is a common pattern in
the software world.

With all of this in mind, I'd like to know how I can help you guys start
practicing TDD? If this hasn't persuaded you, I'd appreciate it if you
would respond and give your perspective so we can talk about it. I'm very
interested in seeing you guys continue to put out great software, but I'm
concerned that as you write more code, you're going to be creating more for
yourselves to maintain and the amount of time you spend writing new
software is going to drop off exponentially as the complexity (as
complexity produces bugs) increases.

Please let me know if/how I can help you.

Craig

Follow ups