DRY and Unit Tests don’t mix well

MattManela — Mon, 13 Jul 2009 06:08:50 GMT

When reading source code, I sometimes come across unappealing code(sometimes even my own). However, there is one kind of “bad code” I see quite frequently. It is a set of unit tests which have had the DRY (Don't Repeat Yourself) principle unduly forced upon them. DRY is the idea that you shouldn’t have to write the same code over and over; abstract it in a function or a class and just call the abstraction. This is all well and good in most cases, but I find it misguided when applied to a test case.

A test case should be like a simple short story. The characters are introduced, action/conflict occurs and then resolution takes place (sometimes with a moral). This (kind of) corresponds to the 3 steps of a unit test: arrange, act and assert. You arrange and setup what you need for your test to run, you perform the action that you are trying to test and then you assert the results. The issue I find is that a coder, in attempting to apply DRY to his test cases, will abstract away all of the arrange step into a function often with a name like SetupExpectations or just Setup. This goes against the point of a test case. A test case needs to be concise and tell me everything I need to know about how that one bit of functionality works. I don’t want to jump around the test class trying to read one test case. To me, this is like reading a book that says, “If you want to learn about the characters in this book please open this other book.” This doesn’t stop you from understanding the test, but it slows you down…and is just annoying.

That is why I will come out and say do not apply DRY haphazardly to test cases.

Code Assumptions

MattManela — Mon, 02 Feb 2009 07:13:42 GMT

My co-workers and I recently came across a piece of code which exposed some assumptions we had about the “correct” behavior of two functions; these assumptions turned out to be false. The code dealt with determining if the IP of a request coming into to a website matches a certain range of IP address. The range of IP address was defined in a config file and could look something like this:

156.27.1.2, 156.*.*.*, 127.0.0.*

Where the * acts as a wild card and each comma-separated IP format is matched against the incoming IP address. The code’s intended behavior is that specifying no IP address formats in the config would mean that no IP addresses would match the format. We noticed that this wasn’t holding true. We went to examine the code that was performing the matching (which none of us had written and sadly has NO test cases around it). The code boiled down to something like this:

        1: bool DoesIPMatchIPFormat(string incomingIpAddress, string ipFormatsFromConfig)

       2: {

       3:     foreach(var ipFormat in ipFormatsFromConfig.Split(','))

       4:     {

       5:         Regex re = ConvertFormatIntoRegex(ipFormat);

       6:         if(rs.Match(incomingIpAddress).Success) return true;

       7:     }

       8: }

Where ipFormatsFromConfig is the ip range of formats shown above separated by “,” or an empty string if no formats are given. On first glance we all were confused by why this didn’t work and then as we looked into it we realized we had made some incorrect assumptions.

First, we assumed that “”.Split(‘,’) would return a zero element array. This assumption is false. It returns a 1 element array containing the empty string.

After we learned this we encountered our second assumption. We assumed that a regular expression whose pattern was an empty string would not match anything. (ConvertFormatIntoRegex returned just that). This assumption is also false. After learning the true behavior, it makes sense why it behaves this way. (A DFA with only one state must accept every input. )

Our assumptions about the “correct” behavior of functions reflect similar mistakes made by all programmers; assuming that you don’t make these kinds of assumptions is a very dangerous way to program and reinforces the importance of unit testing.

Matt Manela's Blog : testing

DRY and Unit Tests don’t mix well

Code Assumptions