The Duct Tape Programmer

It's nice to hear someone with experience from before the "Unit Test is compulsory" explosion. Programmers should always test their work, but testing comes in much more of a diverse range than mere Unit Tests.

There are plenty of cases where Unit Testing is 'embarrasingly'[1] appropriate. These pin-up applications blinds Testing advocates to the fact that Unit Tests are often inferior to other methods or simply not possible.

An example where completely automated tests are impossible is PDF generation. One cannnot 'Unit Test' this. One has to build a framework to take test data, create less than 100 pdfs, and then a human has to eyeball it. Humans cannot eyeball more than 100 images and perceive subtle errors. Less than 100 output images means this cannot exercise every codepath of even simple applications.

Often I was working on a part of the Render Pipeline which was not currently exercised by the existing test. Do I create a whole new test suite to generate test images for each branch condition? If it is important, yes, I created a new end-to-end test. But if it was not, then I addapted some existing test input and used my best judgement and my knoweldge of the internal state. This test did not last beyond my short-term memory, and my own set of eyeballs. If a problem occured later, I would recreate the test from memory.

This is still TDD, but it is so much less straight-jacket than requiring Automated-testing. The tests are 'thrown away' effectively. But the tested code remains. I would also say that the coder knowing which portions to test is superior in many cases.

--------------

[1] Similar to :: http://en.wikipedia.org/wiki/Embarrassingly_parallel . Network stacks, account balances, Frameworks are all embarrasingly unit-testable

Right. I'm not saying become paralyzed due to the risks. And I'm not saying do dumb things that mitigate a risk with an even bigger risk. What I'm saying is don't assume your conclusions. Things that other people might argue are important might not seem that important to you, given whatever perspective you have at the time. It is possible part of the reason they argue for using a certain practice is because they, too, didn't see it as important until they got burned hard for their presumption.

This is not to say they are important. It might be that people are just squawking to sell books or consulting hours or seats at a conference. But, to use a really dumb metaphor, if that many hens are squawking about the same thing, it might be time to look in the barn and see what all the noise is about.

If you don't understand how your object model interact with your threading model, you're DOOMED.

So that means that the majority of us are that duct tape programmers right? but these doesn’t fit, So what’s wrong? well I think there are different types duct tape programmer based on there how smart they are, and that only the really smart ones can successfully write systems without a single test. The remaining programmers use tests to ensure what they have done works, and also hasn’t broken something else.

So given the fact that most people work in teams of programmers of varied skill levels, it makes sense to write tests. And while this might slow the 1 or 2 super smart guys on the team, it will aid the rest of the team.