“I am ready to write some unit tests. What code coverage should I aim for?”

The great master replied:

“Don’t worry about coverage, just write some good tests.”

The programmer smiled, bowed, and left.

...

Later that day, a second programmer asked the same question.

The great master pointed at a pot of boiling water and said:

“How many grains of rice should put in that pot?”

The programmer, looking puzzled, replied:

“How can I possibly tell you? It depends on how many people you need to feed, how hungry they are, what other food you are serving, how much rice you have available, and so on.”

“Exactly,” said the great master.

The second programmer smiled, bowed, and left.

...

Toward the end of the day, a third programmer came and asked the same question about code coverage.

“Eighty percent and no less!” Replied the master in a stern voice, pounding his fist on the table.

The third programmer smiled, bowed, and left.

...

After this last reply, a young apprentice approached the great master:

“Great master, today I overheard you answer the same question about code coverage with three different answers. Why?”

The great master stood up from his chair:

“Come get some fresh tea with me and let’s talk about it.”

After they filled their cups with smoking hot green tea, the great master began to answer:

“The first programmer is new and just getting started with testing. Right now he has a lot of code and no tests. He has a long way to go; focusing on code coverage at this time would be depressing and quite useless. He’s better off just getting used to writing and running some tests. He can worry about coverage later.”

“The second programmer, on the other hand, is quite experience both at programming and testing. When I replied by asking her how many grains of rice I should put in a pot, I helped her realize that the amount of testing necessary depends on a number of factors, and she knows those factors better than I do – it’s her code after all. There is no single, simple, answer, and she’s smart enough to handle the truth and work with that.”

“I see,” said the young apprentice, “but if there is no single simple answer, then why did you answer the third programmer ‘Eighty percent and no less’?”

The great master laughed so hard and loud that his belly, evidence that he drank more than just green tea, flopped up and down.

“The third programmer wants only simple answers – even when there are no simple answers … and then does not follow them anyway.”

The young apprentice and the grizzled great master finished drinking their tea in contemplative silence.

In May 2006, an ill-prepared international expedition to the Himalayas lost its way. After two weeks of wondering around, hungry, thirsty, and smelling like inexperienced expeditioners who got lost for two weeks, they stumbled upon the entrance to an ancient cave.

Once inside, they saw a maze of ancient, and messy, cubicles. Each cubicle had a wooden desk, an ergonomically correct bamboo chair, a Dilbert™ calendar, and a strange computer-like mechanical device. In one corner of the office they found barrels of dark liquid which they later identified as early examples of carbonated and highly caffeinated drink and a ping-pong table. They realized that the cave was an ancient software start-up. The oldest one on record. Older even than Netscape.

Among the many things they discovered inside the cave was a note left by one of the programmers. The expedition’s guide, while not very good at guiding, knew how to read the ancient language and translated the note for them:

We have finished the release ahead of schedule – again. All the tests pass, so we are taking the rest of the week off. We are going sailing. Since it’s a team building exercise, we hope we can get reimbursed for it.

The explorers looked at each other in astonishment. Not only had they discovered the oldest software start-up in history, they had also discovered a team of programmers who, apparently, completed their code ahead of schedule ... on a regular basis!

What was the secret of these ancient programmers?

And what had happened to them?

The expeditioners searched each cubicle for clues and found two mysterious booklets. One of them was called "Learn To Sail In 30 Minutes”, which explained the fate of the programmers. You are holding in your hands a translation of the other booklet: “The Way of Testivus”.

Who wrote this mysterious booklet? What is Testivus? Only Google™ knows for sure.

Is the content of this text responsible for these ancient programmers being able to complete projects ahead of schedule?

We can’t be sure, but we believe that the amazing prowess of these programmers was probably due to a combination of the Testivus philosophy, and the consumption of large amounts of the dark caffeinated liquid found in the cave.

Some developers are easily test-infected - they take to unit testing like a duck to water. Others need some time and encouragement, but eventually "get it". A third group appears to have immunity to test infection. I invent a test-gene model to categorize these groups and look at its implications for the future of developer/unit testing.

On Thursday May 26 Jon Udell interviewed Alberto Savoia. Alberto had just been selected by InfoWorld as one of the 25 Top CTO's in the US in 2005. Jon asks Alberto about his vision for Agitator and Alberto demos Agitator extensively.

You can see the replay now if you don't mind registering. If you do, come back in a few days and we'll point you to an unguarded version.

Jan 27, 2005

–

The Developer Testing Paradox
Most software development organizations have compelling reasons to improve their quality, reduce their costs, and accelerate their schedules. Time after time, and year after year, the majority of software projects are of lower quality than desired, cost more than budgeted, and are completed later than planned. Many projects can only be branded complete failures and have to be restarted from scratch. more »

One of the main themes of eXtreme Programming (XP) is that if an activity is beneficial and worth doing, it should be done to the extreme. If testing is a good thing, for example, we should be testing all the time; in XP this translates to customers doing functional testing and developers writing lots of unit tests and running them several times a day - even several times in a 10-minute period in the most extreme cases. more »

Mar 15, 2004

–

Eating Our Own Dog Food — Using Agitator™ on Itself
In start-up companies, especially in the area of software, the expression "eat your own dog food" means that you should use in-house the products or service that you are planning to sell to other people. At Agitar we take eating our own dog food very seriously. One of the first things I did when we founded the company was to buy a can of Alpo™ dog food for everyone in engineering and put it on their desks to remind them how important it is for us to be users of our own technology. more »

Feb 2, 2004

–

Selecting Developer Testing Metrics
The first step in deciding what metrics to use is to specify clearly what results we want to achieve and what behaviors we want to encourage. In the context of developer testing, the results and behaviors that most organizations should target are the following: more »

Dec 27, 2003

–

Managed Developer Testing
This Developer Testing Note introduces the concept of Managed Developer Testing, a set of management practices supported by automated tools which I believe are essential to make a developer testing effort successful. more »