Unit testing and prime numbers

It has just come to me how easy it is to introduce subtle bugs into even the simplest unit tests. I was just testing some simple method the other day; lets say it was called Multiply for the sake of simplicity:

int Multiply(int a, int b) { /* ... */ }

Well, simply enough, I wanted to test the result of this method. So, I used two integers: 2 and 2, respectively. The test passed with honourable mention. But, it turned out the method Multiply wasn't working properly. 2 + 2 and 2 * 2 both equal 4, right? Multiply was in fact adding numbers instead of multiplying them.

We all know how much more difficult it is to find bugs when tests are misleading. But using simple numbers such as 2 and 2 means that, at least, the tests would have been readable since a fellow programmer could easily guess the expected value of 2 * 2. How can we achieve good readability while avoiding 'result collision' when dealing with numbers?

I find that using simple prime numbers (2, 3, 5, 7, 11) as arguments is a pretty elegant and simple solution. All this may sound trivial, but also avoiding identity values (0 for addition, 1 for multiplication) is also a great way of testing the entire operation (these values tend to cut or skip a part of the computing). These are, however, still important for testing corner cases like dividing by zero.

All of that being said, I tend to apply these rules by default, when the behaviour of the method doesn't dictates the way it has to be computed. This way, a change in the implementation will not invalidate or break tests easily. Plus, these simple values are usually very easy for someone else to compute mentally while reading tests; It doesn't hurt the test's readability.

It's still important to think about special cases when you know about them. I like to consider this approach as a default brainless-mode and go from there. When a value could be anything, I usually introduce the next unused prime number, extracted from my mental list.

How long is your prime number mental list? I can hardly come up with more than 10 without forgetting or making one up.

Posted by: Bryan Menard
Last revised: 22 Oct, 2011 06:52 PM History


No comments yet. Be the first!

No new comments are allowed on this post.