An Introduction to Writing Unit Tests (with CFUnit)

In our last user's group meeting, we had a round table discussion about testing. I said that I would put together a simple example of a unit test.

Since I have been using CFUnit so far (MXUnit looks attractive as well though), that is what I will use for my example. The principles should work the same for any common testing framework.

First I will download CFUnit and install it. This should install a folder "/net/sourceforge/cfunit/". This could either be in the root of the web site or in the CustomTags folder or could be in a folder with an appropriate mapping. The important thing is that components can be called using the path "net.sourceforge.cfunit".

I am going to follow my best understanding of Test Driven Development to create a component that does absolute rounding on a number. In short, this means that I will come up with my tests first and then write my code to get them to pass.

The first thing I will create is my test case component. This will start out empty.

Here is TestAbsoluteRounder.cfc:

Next I will create the code to run all of the test methods (any methods that begin with "test") in this component.

This yields the following result:

Now, I decide how to tell (externally) if my component does what I want. So, I decide on some criteria for success:

• The "absround" method will return zero not passed an argument.
• The "absround" method will return zero if the argument is not numeric.
• The number returned by the "absround" method will always be zero or higher.
• The number returned by the "absround" method will always be an integer.
• If the argument has 5 or more as the first digit after the decimal, then the returned value should have a greater absolute value than the argument.
• If the argument has 4 or less as the first digit after the decimal, then the returned value should have a lower absolute value than the argument.
• If the argument is an integer, then the returned value should be the same as the absolute value of the argument.

If the component passes all of these tests then it performs the desired function.

Next I will create a setup method in my test component to call the AbsoluteRounder.cfc component and create the empty AbsoluteRounder.cfc.

setUp:

AbsoluteRounder.cfc:

Now I add the first test:

Note the user of the word "should". I got this idea from Peter Bell and I have found that it works well. The advantage is that the name of the tests describes the expected result. This naming conventions helps encourage me to write the sorts of tests I should be writing.

So, here is the completed test component:

The result of this:

I got errors because I haven't even created the method yet. So, I will create a method:

Now my tests return a result of this:

My method exists, so I don't get any errors. I still get failures, however, as it doesn't do what is needed.

Now I will write my method to achieve the desired result:

When I run my tests now, I get success:

I think it is important to comment here that while I think this entry does a good job of showing how to write test cases and go through Test Driven Development, it does an awful job in demonstrating why you should go through that process. That will have to wait for another day.