For a Man With a Nail, Everything is a Hammer

A good software engineers is a practical purists. He loves the purity of code and methodology, but he lives in the practicality of shipping a product. Sometimes I’m faced with a nasty piece of functionality, and I know that if I could just have a few weeks, I’d be able to gracefully build a beautiful and complex system that will be maintainable and work. But I only have a day, so I solve it with duct-tape and spit. I know I’ll feel guilty about it for the rest of the week. And then I’ll feel bad about it again, when we’ll find bugs in the code. And we will.

A Unit Test A Day Keeps The Doctor Away

Unit tests are small automatic tests for little pieces of functionality. Good unit tests will help you realize bugs near the time you have written them. That’s great because fresh bugs are easier to fix. However, there has been a surge of unit-test-fanatics, who claim this is the one-true-way of software development. They shun any other QA methodology. Tests, they say, are more important than code. So we’ve seen the rise of TDD, BDD and I-don’t-know-what-else-DD, and they are going forward at such a speed that there is no way for the rest of us to catch up.

I don’t like writing unit tests. They bore me, and I hate writing boring code. Jeff Atwood seems to get both sides of the argument:

Even if you only agree with a quarter of the items on that list– and I’d say at least half of them are true in my experience– that is a huge step forward for software developers. You’ll get no argument from me on the overall importance of unit tests. I’ve increasingly come to believe that unit tests are so important that they should be a first-class language construct.

However, I think the test-first dogmatists tend to be a little too religious for their own good. Asking developers to fundamentally change the way they approach writing software overnight is asking a lot. Particularly if those developers have yet to write their first unit test. I don’t think any software development shop is ready for test-first development until they’ve adopted unit testing as a standard methodology on every software project they undertake. Excessive religious fervor could sour them on the entire concept of unit testing.

That is why I’ve developed the  Stolen-Tests-Development practice

Stolen Tests Development (STD)

The last few weeks, I’ve been writing a database middleware. This product can parse SQL and then do some logic before passing the command to the database. Building an extensive test suite for a product like this is almost impossible. SQL is one of the most complex, free-form, high-level languages there are.

My test cases are filled with SQL queries and expected outcomes, but there is a limit to my mental-capacity to produce these long and boring lists of tests. Soon enough I’ve felt like driving an icepick through my eye.

Select * from a1

Select col1 from a1

Select col1, col2 from a1

Select * from a1 alias

Select * from a1, a2 where a1.col1 = a2.col1

Select monkey_name from mad_table where drive_number is not null

This can drive a monkey mad.

So, I’ve started thinking. How can I test my program, extensively, while writing a minimal number of tests? Steal really good tests. Django is an extremely popular web development framework. I love it. One of the things that make Django so incredibly awesome is that the core-development team really understands the importance of good tests and documentation of their product. This means you can use the bleeding-edge development version of Django in production and it’ll probably work fine.

One of the features of Django is the ORM, the Object-Relational-Model, which takes care of the persistence of the objects in a database. What I’m doing is providing Django with a DB back-end that connects to my middleware instead of MySQL. Now I can run the entire Django test-suite against my software. If this works, I have successfully tested my entire product (integration included), with Django. I feel very Django-certified.

Then, the only tests I have to write are the one regarding the core-logic of my middleware.

I bet there’s also good test-suite for MySQL and Rails. Anyone else I can get my STDs from?

I don’t like writing unit tests. They bore me.