Java J2EE Portal
Enterprise Java Station
J2EE curve
Java News / Articles
Java News / Articles
Integrating BPEL, Human Workflow and Business Rules in Java EE
Is EJB Relevant Anymore?
Bridging the Microsoft and Java worlds
Processing...
Buy Java, Deals On Software Technology Store
Click here for great deals on computers, laptops, software and books
Test Driven Development doesn't fit my brain PDF Print
Written by Content Team   
Jun 15, 2006 at 02:54 AM

TitusBrownTitus 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

Related:
>> The good and bad of XP and Agile notions of software testing ...
>> Understanding Agile: 1-2-3 and you are agile!
>> Why pick JTiger Java Unit Testing Framework over good old JUnit ...
>> Which Java unit testing framework suits you best? JUnit, TestNG ...


User Comments
Your Name / Email Address
Comment
Spam Protection - Please enter the code in the image -

Listen to code


Add This Feed Button

Enter your Email


Java Expert Interviews
RoelStalmanOracleJDeveloper
JDeveloper is the most comprehensive Java IDE available
PatrickLightBodyWebWork
Struts Action Framework 2.0 should be released by August 2006
Debu Panda - Oracle
Oracle Application Server is the fastest
Processing...
Go to top of page  Home |
SiteMap

Copyright 2004 to 2008 Rightrix Solutions. All rights reserved. All product names are trademarks of their respective companies. Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. Rightrix Solutions and IndicThreads.com are independent of Sun Microsystems, Inc.

Views expressed at IndicThreads.com reflect the views of the authors alone, and do not necessarily reflect those of IndicThreads.com. IndicThreads.com and it's authors are not responsible for reader comments and opinions.

Enterprise Java J2EE JEE Portal >> IndicThreads.com