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?
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 CowOrker
s 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)
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.
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.
, 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 UnitTest
s) 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 R
ealProgramming(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?