Test Driven Development doesn’t fit my brain

June 15, 2006February 4, 2010 Content Team 2982 Views 0 Comments agile software development, frameworks, Interviews, Java, Java Interviews, Python, test driven development, testing

TitusBrown Titus Brown is a well known name in the Python community. Apart from his work in Python, he is also a speaker on Agile development. In a recent interview with PythonThreads.com, he shared his thoughts on agile and test driven development.

PythonThreads >> Could you list 3 things that you find most impressive about the agile way?

Titus Brown >> Rapid prototyping, testing at all levels, and short iterations. I consider “rapid prototyping” to be an excellent alternative to “big design up front”, and I consider “short iterations” to be a good solution to the sort of large-scale breakage that occurs between releases in many projects. Testing at all levels should go without saying: unit tests say nothing about UI functionality, and neither do functional tests; acceptance and regression tests are beasts that will catch other problems than functional and unit tests. Test from as many directions, at as many levels, as possible.

“Rapid prototyping, testing at all levels, and short iterations….”

PythonThreads >> Some believe that with Agile Testing there’s no need for a separate testing team. The developers are the testers. While others feel that the agile guys are taking a very narrow approach to testing. Where do you stand on this?
Titus Brown >> Dogmatism is bad, and anybody who asserts that there’s *no* need for a separate testing team is probably smoking something fun, or is a consultant looking to make some money fixing your problems.

I’ve rarely come across a situation where additional perspectives were bad, and that includes testing. That having been said, I firmly believe that the best code-facing testers are also going to be moderately serious developers (or at least people with that potential). However, developers are typically disastrous at UI testing, and I can’t even imagine letting the dev team design the acceptance tests.

Developers are typically disastrous at UI testing…”

Some sort of exploratory testing is usually a good idea, too, and that can be done by anyone. So my succinct answer is this: were the agile guys truly saying that there’s no need for a separate testing team, I’d think they were taking a narrow approach. I think it’s a straw man argument, however, and discussion on the agile-testing list supports this: there are many wise and experienced testers on that list who would be skeptical of that argument!

PythonThreads >> In your experience, what are the primary advantages of a Test Driven Development (TDD) approach as compared to older techniques?
Titus Brown >> Grig may shoot me for writing this down, but I have a really hard time with TDD myself; it doesn’t fit my brain. I prefer what Grig named “Test Enhanced Development”, where code may or may not be *developed* with tests, but tests (at all levels — unit, regression, acceptance, etc) are added throughout the development process. This could be because I tend to code *really* fast when starting a project, and then rewrite large sections of the code (within a few hours or days) as I figure out what I need to do. Writing tests first would add serious overhead, although I suspect TDD advocates might suggest that I wouldn’t need to rewrite code if I did it their way. Whatever, I’m not doing it their way and I’m not planning to change soon — maybe next year ;).

” Writing tests first would add serious overhead…”

One particularly useful procedure of both TDD and “TED” is to write unit tests for each new bug found: this lets you precisely identify the source(s) of the bug and also ensures that it never re-occurs! I embraced agile testing as a force multiplier for my own research projects, and this is really its continuing utility for me. Since I mostly work alone and simultaneously on many different research projects, I use the tests to prevent “bit-rot” in my own software and also use them as enforceable API documentation. I’m sure this is a sloppy set of habits, but again, it works fairly well for me!

So, succinctly, the advantages (for me) of a TDD-like approach are that it serves as enforceable API documentation, stops bit-rot in the parts of the software you’re not focused on, and kills bugs permanently.

“I use the tests to prevent “bit-rot” in my own software ….”

For the entire interview visit: Python community is extremely active in building agile testing tools