The Lazy Unit Tester

My take on unit tests? Essential!

Never mind that SalesForce.com forces 75% code coverage on any code written. Even if this mechanism wasn't there, I would still insist on them being present on any solution implemented by myself or my team.

A unit test is, at its most basic level, code that tests code! It's not a replacement for smoke, functional or system testing; it's a mechanism which helps improve the quality of code written by developers.

If you’re building a car, it’s the sum of all its parts. The parts are manufactured individually, then put together and at the end of it you have a working car! Quite a simple process, like a jigsaw puzzle, but a lot can go wrong in this process.

Let's take the wheels on the car. For the car to run you need four wheels, each with tyres. They all need to be the correct size, shape and inflated to the correct pressure to be useful. If one of those wheels is square, the wrong size or is flat then this will affect the operation of the car and make it less than desirable to drive or own.

When buying a new car, you hope the manufacturer tests the individual components (in this example the wheels), as well as the overall function of the car.

Now, onto the geekery, let's take this code example

public class Wheel {
    public static String defaultBrandName = 'Default Tyres Inc';
    public static int defaultSize = 14;
    public static double defaultPressure = 33;

    public String brandName;
    public int size;
    public double pressure;
 

    public Wheel() {
        this.brandName = defaultBrandName;
        this.size = defaultSize; 
        this.pressure = defaultPressure;
    }

    public Wheel(String brandName, int size, double pressure) {
       this.brandName = brandName;
       this.size = size;
       this.pressure = pressure; 
    } 

    // Some Accessors and Mutators for the instance variables
}

public class WheelFactory {
    public static Wheel getWheel() {
        return new Wheel();
    }

    public static Wheel getCustomWheel(String brandName, int size, double pressure) {
        return new Wheel(brandName, size, pressure);
    } 

}

It's quite clear how this now works. We go to the wheel factory and either ask for a default tyre or we specify what kind of tyre we want, as the meerkat says 'Simples'. but what would be the best way to test this to enable me to deploy it to a SDFC production org? Not much I hear you say, but here is an example of the type of thing I have seen.

@isTest
public Class WheelFactoryTest {

    public static testMethod void myUnitTest() {
        Wheel w = WheelFactory.getWheel();
        Wheel w1 = WheelFactory.getWheel('Pirelli', 20, 33);
    }
}

And there is it, as far as Force.com is concerned, a perfectly valid unit test! It makes the 75% test coverage requirement and took about 30 seconds to write. Job done! Let me ask you this though, what is my unit 'TEST' actually testing? The simple answer is that it's testing that the WheelFactory and Wheel classes compile and can be called. It's quite frankly a waste of 30 seconds and this test is useless! Is a Wheel being returned? or is it returning a null? What brand is it? What size? What pressure? We just don't know from this test! Below is what I would consider a better test of this:

@isTest
public Class WheelFactoryTest {

    public static testMethod void wheelFactoryGetWheelNoParamsTest() {
        Wheel w = WheelFactory.getWheel();
        System.assert(w != null);
        System.assert(w.getBrandName() == Wheel.defaultBrandName);
        System.assert(w.getSize() == Wheel.defaultSize);
        System.assert(w.getPressure() == Wheel.defaultPressure);
    }

    public static testMethod void wheelFactoryGetWheelWithParamsTest() {
        String brand = "My Brand";
        int size = 17;
        double pressure = 35;
        Wheel w = WheelFactory.getCustomWheel(brand, size, pressure);
        System.assert(w.getBrandName() == brand);
        System.assert(w.getSize() == size);
        System.assert(w.getPressure() == pressure);
        
}

Hopefully you can see the improvements here?

1. We are testing each method in a clearly separate way so if one method fails we know instantly which one is broken
2. We are using asserts to guarantee that we are getting the correct results! When you see a unit test with no asserts you need to change that! 95% of the time there is no excuse for a unit test with 0 assertions this is testing more than just coverage!
3. We are protected from change! Because we are using the static default variables from the WheelFactory class in our tests, if those defaults change our unit test does not need modifying, this is basic coding 101, don't use magic numbers!
4. I am actually testing that the tyres are the correct size, pressure and brand! Wouldn't you do that in real life if you were buying tyres for your own car?

Hopefully people will find this useful and when they get given a unit test to write will do the right thing and do it properly and understand the importance of a well constructed unit test!