Enemy Unit Testing

I'm a big advocate of Agile Methods and principles. I believe quite simply that an evolutionary design, refactoring, user stories, and especially Unit Testing. So when I came across the concept of Enemy Unit Tests, I was dumbstruck by the logic of it.

Think about it. When we right code, we write Unit Tests (hopefully!) and run them as often as necessary. You may not run all of them all the time, but you run the important ones as often as possible.

Now what about all those libraries you're using? When was the last time you tested those?

I don't mean that you should test each and every library in use anywhere in your project. That's a bit overboard and probably going to be way too expensive and time consuming to ever become effective. I'm talking about something much simpler.

Not sure about the reliability or the stability of a library? Write a Unit Test! Have you just upgraded a core library of the system? Write a Unit Test! If nothing else, confirm that the fingerprint of the functions/member variables haven't changed over time.

Let's face it... not every developer is as intelligent/diligent/creative as you *cough*cough*, you don't know the other developers, what their motivations are, where their loyalties lie, or even if it's their first release. I'm not ascribing nefarious motivation to these people, it could be a simple conflict of priorities. It's as simple as this: If you're using a math library which is optimized for speed, what happens when the next version comes out and it was optimized for precision? Will it make a difference to your application or will it melt the computer and destroy life as we know it?

There are a multitude of libraries out there - open source or not - that can speed along development and prevent us from re-inventing the wheel. Unfortunately, since we are not inventing them from the ground up, we must evaluate them and make sure that the new functionality/bug fixes don't break existing code.

Did this recently


Not sure about the reliability or the stability of a library? Write a Unit Test!

I did this recently to test PHP CTYPE functions. They of course, worked as expected, and I learned alot about them while using them :)

Always a good idea

As I found out recently, to my chagrin. My company's app runs against Oracle and SQL Server, and during performance testing, it was found that Oracle was stompin' SQL Server but hard. After much profiling and UTs, it was discovered that (surprise!) Microsoft's JDBC drivers are a little... inefficient. Switched to the open-source jTDS drivers and now SQL Server is outperforming Oracle at times.
Hmm, time to test those OCI drivers...

That was our reason

A screwy database driver was what triggered this for my customer. We were using a JDBC driver which would allow us to return the null value of "0000-00-00" which is not technically a valid date. The next version of the driver will allow you to INSERT that value, but not SELECT it.

Therefore, when we upgraded the driver we had to catch that exception all over the place and then return the "0000-00-00" value because older code was using that as a flag. Arg.