I come from a background that strongly emphasizes automated testing baked into the build process. You commit, the code is checked out by the build system, compiled, and tests run against it. If it fails, the artifacts are discarded and cannot even be sent for manual testing. After all, what's the point if even the automated tests are failing? Those are the easy stuff!
When I moved on to my next gig, you may recall I didn't have that same luxury. There was little to no emphasis on automated testing, and was largely considered a waste of time. I actually had one business manager say "Can you imagine how busy your developers would be if they had to go fixing all those bugs? We'd never get anything done!" You can't make this kind of stuff up.
Well now I find myself in a happy medium. There's no tests around this code either, and there's no automated build engine, but that's okay. The folks here are very happy to look at new techniques, incorporate them when you can, and preventing bugs is largely considered a Good Thing. Great. Naturally, I asked if there were any projects that used JUnit (it's a Java gig) and was told no, there's not. But, if something needs to be verified to be correct, it is done at system startup. Here's a code example of how it might work.
public class DateTimeUtility {
/* returns true if 'late' is later in time than 'early' */
public boolean isAfter(Calendar early, Calendar late) {
return late.compareTo(early) > 0;
}
/* verifies the integrity of the isAfter method */
static {
Calendar early = new GregorianCalendar(1999, 1, 1);
Calendar late = new GregorianCalendar(2000, 1, 1);
if(!isAfter(early,late)) throw new Error("DateTimeUtility.isAfter is broken");
}
}
It doesn't have the fancy features that a unit testing framework would have, but it does appear to be quite useful. Now, date time utilities aren't exactly something that break often, but it's just an example. Clearly something more complicated can be substituted.
The pros I see is that it would be literally impossible to have a failing test in any environment. If you have a bug with one of these tests around it, it simply won't work. (I suppose technically you could catch the Error, but that's a particularly bad practice to be getting into, considering the Error contract.)
The cons would be that you end up with a larger artifact (as the tests are bundled into the artifacts you'd be sending to production) and, depending on the thoroughness of the testing, could have a significant increase to the boot time of your application.
It's not a widespread practice among the team, but it does show up on occasion. Of course, you'd never know it was there unless you looked for it, because needless to say any problems with it don't last long. The first time you load it into your dev environment it explodes spectacularly.
Is this a practice that was a fad at one point? Maybe it goes by a special buzzword? Has anyone run into this and might be able to provide some insight into it, its pros and cons, and other special considerations I'm not seeing? Is it a flat out bad idea and I should actively attempt to migrate these blocks to a bona-fide unit test?
