

Handling Intermittence: How to Survive Test Driven Development - jmathes
http://joblivious.wordpress.com/2009/02/20/handling-intermittence-how-to-survive-test-driven-development/

======
speek
As much as TDD irks me to think about when I'm in the middle of a program,
it's a very useful thing.

Its saved me from making countless mistakes.

JUnit isn't good for beginners though, because you have to define an equals
method for each class. Not only is that completely repetitive, but it is also
very difficult for beginning programmers to write good tests. If you haven't
been programming for very long, how do you know how to define equality? Do you
consider two objects that have the same fields (only the fields you're
testing) to be equal? Or are you checking whether or not two objects are the
same (bit for bit in the stack)? What happens when you have super-classes that
have less fields than their subclasses?

Anyway, one of my professors is working on a new tester for java
(<http://www.ccs.neu.edu/javalib/Tester/index.html>). It's very elegant; the
syntax is very clean:

"public void testGresterThan(Tester t){

    
    
         t.checkexpect(7 > 4, true);
    

}"

------
CalmQuiet
Although my projects are small and not currently using TDD, I found this
analysis in systematizing development strategies. Present five ways of
breaking down ways you set yourself up for intermittent failures during
development:

Hidden data dependence

Race conditions

Time sensitive tests

Unstable 3rd party software

Intentional randomness in code.

------
lgriffith
TDD means you write your test before you write your code.

Test code is code. You must write test code for your test code before you can
write your test code.

Test code for test code is code. You must write test code for your test code
for your test code before you can write your test code for your test code.

TDD is trapped in a loop of infinite regression. This means that TDD never
produces actual application code. In fact, it can't even produce test code.
How do you define a test of a test of a test .... of a test ... of a test
..... so you can write it? You can't define it so you can't write it. You have
no starting point.

The answer must be that you really cannot do TDD. You just call it TDD. At
some level you rely on the old standby of clean simple design, incremental
implementation, inspection, and manual testing. Why not cut to the chase and
do that on your application code?

~~~
jmathes
Each test you write is a value-add. You get increased safety that what you're
testing works the way you think it does, and that it will continue to do so as
people modify it. Not all cases need to be tested; "test to your level of
paranoia" is our motto. In the case of tests themselves, the value add for
testing individual tests has never been worth the ROI. There are, however,
tests for the testing _system_, insofar as that's possible (which it is, for
the most part).

As for the "I happen to view TDD as a completely obnoxious and unnecessary
exercise" objection, I'd be willing to bet you've never tried TDD. It doesn't
take long for proper TDD to _save_ you time. Each iteration cycle is slower,
but the marginal cost for adding new code to a complex codebase doesn't
increase nearly as much.

Without TDD, you soon have to spend time on manual testing, and then you've
got humans in QE basically practicing TDD for you, as the walk through script
after script doing things that could be done faster by a computer. The only
time it's appropriate to consider skipping TDD, IMO, is on tiny one-man
projects.

~~~
lgriffith
I see. TDD works on poorly designed, poorly implemented, basically lousy code.
Code that is highly coupled, withlow cohesion, and is inappropriately
modularized. This necessitates that all code must be tested every time there
is a "modification". Add to that the random unthoughtful modifications made by
careless programmers who have identified the wrong problem to fix and you get
constant disaster.

I say, fix the fundamental problem by not writing lousy code in the first
place. THAT would really be adding value rather than simply adding job
security busy work. Automated testing cannot fix lousy code. Most of the time,
it can't even discover it.

There is no magical way that gets good results without knowledge, skill,
understanding, thought, discipline, and effort. With those things, all you
need are good enough tools. TDD may be one of those good enough tools in some
limited circumstances. It is not a _Silver Bullet_ that cures all, most, or
even many software flaws.

Keep in mind that one really good programmer can out produce a team of twenty
poor programmers. Also keep in mind that one poor programmer can keep twenty
really good programmers busy cleaning up the trash they create.

TDD is a very poor band aid used to cover up an even more fundamental problem:
most programmers are lousy at programming. That is the problem that need
fixing.

~~~
teej
TDD is like bumper lanes at a bowling alley. If your goal is to knock down the
pins, it can help prevent problems, like falling in the gutter.

Of course, if you're incredibly good, you don't need the bumpers. You might
even forego bumpers to show off that you are -that good-.

Your solution is to make all the bowlers really good. Here's the issue -
historically, that doesn't scale across a growing dev team.

Imagine 5+ bowlers all using the same lane. The more bowlers you have, the
more you will have balls bumping into each other, getting in the way, crossing
paths, and falling into the gutter.

As you increase the number of developers, the more likely it is that tools
like TDD and Source Control can help mitigate issues that inevitably arise on
a larger team. They aren't silver bullets to great programming, and they
aren't a bandaid to cover up bad programming. They are time-tested, proven
ways to get people going the right direction.

~~~
lgriffith
"Imagine 5+ bowlers all using the same lane. The more bowlers you have, the
more you will have balls bumping into each other, getting in the way, crossing
paths, and falling into the gutter."

I suggest THAT is the problem. TDD is a band aid to cover the fact that such a
team cannot function. The right team of <=4 can blow the roof off of ANY team
of 5+ based upon communication network overhead alone. If you don't have the
right team, you are hosed no matter what.

