Test Infected

Help! I've fallen! And I can't reach the test button!!! -->

What a developer becomes the first time a test suite pin-points a bug and saves him hours of debugging time.

The phrase was coined by ErichGamma in the documentation for JavaUnit.

Also the name of an article by GammaAndBeck?: http://junit.sourceforge.net/doc/testinfected/testing.htm.

I prefer the expression TestHappy. I get happy when I write and build a battery of tests. I don't feel infected! -- JoshuaKerievsky

Both expressions are fine, but neither is as lovely as the DawningLight? that shines ever-so-gently from the developer's smiling face.

Winding down at the end of a recent project, I found myself getting annoyed at my CowOrkers who were hanging around in small groups and chatting for hours just to pass the time. I was busy -- doing testing of all things! My God! I've been infected!!!

Since when have I seen anyone (myself included, unfortunately) who wanted to pass the time by doing testing?

Well, when testing becomes an investment that will pay dividends over time, instead of being just a slow, tedious and ineffective process, then it's suddenly more attractive. -- JeffGrigg

So, how do I get my co-workers TestInfected? Here's the situation: I have support from the CTO/Technical Lead, and InTheory, everyone below is supposed to be doing so, but there is a very tight link between our code and the database.

I often hear "I tried to write a UnitTest, but it's too much of a pain to create database information". The general result is that the objects that most need unit testing are the ones that are not, and I spend "extra" time writing virtual database objects, but I feel like things are being done the hard way all around.

-- KaelLizak, feeling like a voice in the wilderness....

Databases raise specific issues with UnitTests; for strategies on how to cope with these technical concerns, see UnitTestsAndDatabases.

But as far as the social & political aspect of your question: Are there any parts of the code that aren't tightly coupled with the database? Those are much easier to write UnitTests for.

There are utility objects that are not tightly coupled with the database, but they are generally the Exception.

As a side note, be wary of any product where the entire code base is tightly coupled with a database.

I more or less agree with you, but i) I'm really JustaProgrammer who's been lobbying for an idea I believe in (that would be UnitTests) and ii) Since the company I work for is an ASP, our product isn't sold, so it might be acceptable (did I mentioned that I'm not all that experienced?).

That said, thanks for the pointer.

To give you a better idea of the environment, each client has different content in our system. User test content, look and feel information, (including XSL) and user's responses are all stored in and retrieved from the database. Nobody else ever gets our code. Right now, I'm trying to push for unit testing the Java, but I'm hoping it'll trickle into the XML processing and report generation. -- KaelLizak

Today while coding, I realized that sometimes I am just as happy to see the red bar that means I wrote a test that reliably fails, as I am to see the green bar that means I satisfied the test afterwards.

We all slip sometimes and don't always do TestFirst. Sometimes we're lazy, sometimes we think we're too busy, sometimes the environment just is too hairy to deal with testing right now. I've started noticing that I no longer feel like I'm doing RealProgramming(tm) in this mode. Does anyone else HaveThisPattern? Indeed. Usually, this happens when I'm in and around LegacyCode - those times when the ReturnOnInvestment for trying to push some code into the wonderful world of testability is simply too low.

Coming soon (or maybe not) ---> TestAddicted?

CategoryTesting