TDD doesn't suck

[Chris Dollin]

Does this imply that "TDD" is not used by C programmers,
and that the way to do TDD is via general tools like JUnit ?

No.

(You do need something to make writing and running tests easy.)

That's at best some silly assumtions.

I'm not sure which, if any, of these Phlip is making.

Who's next after Phlip to tell us how to save the world btw ?

I'm game. But what does saving the world have to do with software
development?

 

[goose]

http://groups.google.com/group/comp.software.extreme-programming/msg/322c15e17cd04145

Whence: http://tinyurl.com/r8pna

Now that I've had a quick shufti at it, I have to say that
I don't really see what all the fuss is about. This just looks
like a formal method of testing code, no?

Okay, so you've got the coloured bars and you've added
in a few big words, but it still boils down to just
"test the code you've written", hmm?

I thought all professionals test each function/routine/etc
that they write, preferably keeping the test calls in
a seperate module and writing the test results to a single
output file.

I'm currently working on a (home/hobbyist) project were
my modules consist of a .c file and a .h file. A seperate
test.c file has routines named the same as the modules, to
test each module: e.g.
1. foo.c -> all the foo_* functions.
2. foo.h -> all the foo_* prototypes.
3. test.c -> has function
int main(void)
bool foo (FILE *output)

When compiled, then linked and run, the main module
calls all the module fnuctions with a file that they
can write to (as verbosely as they see fit).

After it all ends, I can diff the results file with whats
in source control to check if anything went wrong, or add
it to source control if a new test function was added to
test.c.


How do the restrictions placed by TDD help in any way?

goose,

 

[Ian Collins]

Now that I've had a quick shufti at it, I have to say that
I don't really see what all the fuss is about. This just looks
like a formal method of testing code, no?

Okay, so you've got the coloured bars and you've added
in a few big words, but it still boils down to just
"test the code you've written", hmm?

Certainly not, it's more like "write the code you have tests for". The
tests come fist. That's the big difference.

How do the restrictions placed by TDD help in any way?

What restrictions?

 

[Phlip]

Now, folks, you're going to need two long pieces of string, a cereal
packet,
some sticky-backed plastic, a washing-up-liquid bottle, and a sharp pair
of
scissors...

Cue Monty Pythons's infamous "How to Do it" sketch!

 

[Richard Bos]

This thread ain't about what's the best C unit test rig. Google says this
one is:

Google makes value judgements, now? Good! Maybe you can ask _it_ what
the Gratest Evvurr!!! development strategy is, and leave such off-topic
tripe off comp.lang.c.

Richard

 

[Phlip]

Google makes value judgements, now?

It ranks pages based on how many other pages link to them, so it generally
collects a vote of the value judgements of all those page authors.

Good! Maybe you can ask _it_ what
the Gratest Evvurr!!! development strategy is

Well, Google's own programmers use TDD, so...

 

[Charles Richmond]

Cers:

The majority of the world's legacy software is written in C.

Well, you started out right. The majority of legacy softwre is
written in COBOL. (For scientific and engineering work, the
majority of legacy software is written in FORTRAN.)

 

[jacob navia]

Well, you started out right. The majority of legacy softwre is
written in COBOL. (For scientific and engineering work, the
majority of legacy software is written in FORTRAN.)

All software is legacy anyway.

Before your fingers leave the keyboard, before you have time to
reflect, whatever you have written is just "legacy" for this
field that is always reinventing the "new and improved" wheel.

Yes, great invention the wheel. But it is a legacy application.

 

[Phlip]

All software is legacy anyway.

The majority of the software that I use, that is still relevant to
programmers and users, that drives the internet, is written in...

 

[Al Balmer]

Well, Google's own programmers use TDD, so...

As I recall, you were challenged on that long ago, in another
newsgroup, and the whole thing sort of faded away ...

 

[Phlip]

As I recall, you were challenged on that long ago, in another
newsgroup, and the whole thing sort of faded away ...

http://www.xpsd.org/cgi-bin/wiki?PreviousPresentations

"July 6th, 2006

"Agile Software Development Case Study: Google

"Ian McFarland, a principal at Pivotal Computer Systems, and author of
Mastering Tomcat Development, will talk about applying Agile practices on
large, real-world projects, specifically drawing on his experiences with
Agile software development at one of the worlds fastest growling companies -
Google..."

The slideshow is members-only, but its TDD slide says this:

Code Quality and TDD

* In one application built on the platform, one
subsystem was not test-driven, and not developed
using agile practices

* One non-Agile, non-TDD subsystem comprised
<10% of the code, but was the source of ~75% of
the bugs

* The non-Agile subsystem missed its release dates,
and pushed the release date of the whole
application, by 4 weeks. (From a 12 week planned
release cycle.)

So not only do they use it, but they did the in-house research needed to
show it works. For them.

Oh, and it probably wasn't C. ;-)

 

[Al Balmer]

http://www.xpsd.org/cgi-bin/wiki?PreviousPresentations

The previous discussion I remember was some time ago, and it turned
out that Google was in the process of contemplating Agile development
techniques. (Although the implication then, as now, was that Google
used it widely and routinely.) It may be that this study was the
outcome of that contemplation. Unfortunately, it's not possible to
critique the study from the information provided.

 

[phlip2005]

The previous discussion I remember was some time ago, and it turned
out that Google was in the process of contemplating Agile development
techniques.

They have been adopting them for years - specifically to clean up the
"continuous deployment" path between their engineers and their huge
server farm.

I found you an online version of the slide show:

http://www.javamug.org/mainpages/presentations/AgileDevelopmentatGoogle-DallasJUG.pdf

( http://tinyurl.com/lb8sv )

Note that it's a slide show, not a peer-reviewed scientific paper in an
academic journal.

But note that Ian does not seem to mind touring with this slideshow,
and that might possibly imply he answers the occassional hard question.

(Although the implication then, as now, was that Google
used it widely and routinely.) It may be that this study was the
outcome of that contemplation. Unfortunately, it's not possible to
critique the study from the information provided.

http://weblogs.asp.net/rosherove/archive/2004/12/02/273833.aspx
"Test Driven Development proves useful at Google"

These are notes on a slideshow, possibly Ian's:

"current status: very stable builds due to unit tests, better stability
in backwards compatibility due to unit and functional tests. More TDD
in future, with many more tests. Goal is to get to a stage where XP and
testing offers benefits beyond build stability and backwards
compatibility--much more quality in production software."

I think the vibe is a few years ago they were adopting, and nowadays
they are adopted, and not shy about it.

If you need more /argumentum ad auctoretatem/, you can also try
Microsoft. (Remember them?

 

[Richard Bos]

It ranks pages based on how many other pages link to them, so it generally
collects a vote of the value judgements of all those page authors.


Well, Google's own programmers use TDD, so...

....that proves that TDD does evil.

Richard

 

[Phlip]

goose wrote:

What restrictions?

You know, nuisances like "only write testable code". Stuff that infringes
our freedom as programmers to write whatever we like...

 

[jmcgill]

our freedom as programmers to write whatever we like...

vanishes to varying degrees whenever we work on a project with, for, or
managed by others...

 

[goose]

You know, nuisances like "only write testable code". Stuff that infringes
our freedom as programmers to write whatever we like...

If your religion can only be defended by
intentionally incorrect attributions, most
sane people will decide that it can't be
very good, then.

You want people to take you seriously? Stop
acting like an adolescent boy who just
discovered the second use of the penis.

I generally hate to come down heavily
on anyone, but I suggest that you bear in mind
that its difficult for people to think that
anything you suggest can be any good if
you have to resort to inflammatory and
flame-attracting statements to make your
point (see above).

I tried it, and reported on my experience
as honestly as possible (if anything,
I erred on the side of TDD in my reporting
so that I wouldn't unduly cast TDD in
a bad light). I basically compared what
I normally do with TDD and TDD came out
slightly behind; sorry - TDD would have come
out ahead if "the way I normally write code"
was a mess with no structure or forethought.

TDD, done like the way you said, had resulted
in an undetected bug in my toy project.
After detecting the bug (by *inspection*,
nogal), I fail to see a benefit at this point.
The code in question is downloadable from
www.lelanthran.com/downloads/os_mem

The fixed version (bug found accidently by
inspection) is downloadable from
www.lelanthran.com/downloads/os_mem2

Bug is in function find_ptr(), in
file os_mem.c. No test exists that would
have been certain of catching this bug.

Enjoy.

goose,
You might be able to see why I disbelieve
ridiculous claims if you weren't so
ego-invested into proving that TDD is
best for everyone, in every situation
and at all times. OTOH, I've not invested
my ego into proving or disproving TDD.
I think it's excellent for the
undisciplined or newbie developer.