R2013a, the latest semi-annual MathWorks product release, just went live. One of the significant new capabilities in the MATLAB release is a new unit test framework (overview video, documentation). I am very happy to see this!

Long-time blog readers might be wondering, though, what about MATLAB xUnit? This is a unit test framework that I created and put on the File Exchange. I first wrote about it in this space in 2009. It is my second most popular File Exchange contribution (over 200 downloads in the last 30 days).

Today I want to recap how MATLAB xUnit came to be, explain what will probably happen to it, and convince its users to give the new "official" unit test framework in R2013a a try.

I learned to write unit tests when I came to MathWorks in 1993 as a new software developer. I've used several generations of test frameworks created for internal use here. Until recently, our internal testing machinery was tightly coupled to the entire system we used to build, test, and release our products, and so it was impractical to use it for small projects. This became an issue for me sometime around 2002-2003, as I was working on the first edition of Digital Image Processing Using MATLAB. As the "software guy" among the three coauthors, I was responsible for overseeing the MATLAB functions in the book, including making sure that everything was working OK. So I wrote a simple test harness that exercised the book's examples and some of the functions.

Later, the MATLAB R2008a release included the new generation of object-oriented language features. I was interested in learning more about it. Coincidentally, I had just read Kent Beck's Test-Driven Development, which included a case study on using test-driven development methods to create an xUnit-style test harness. I decided that would be an excellent project with which to learn about test-driven development as well as the R2008a MATLAB language changes. (With the wisdom of hindsight, I have to say here that I don't actually recommend learning test-driven development by using test-driven development to develop a test harness. It hurt my brain too much.)

Anyway, sometime in the spring on 2008 I had something pretty basic working. At about that time, Greg Wilson (original creator of Software Carpentry) visited MathWorks to give a talk about his edited book, Beautiful Code. I met Greg then, and we talked about the needs of MATLAB scientific users. Greg encouraged me to turn my fledgling tool into something real. He also invited me to write up something for the IEEE magazine, Computing in Science and Engineering. That became the article "Automated Software Testing for MATLAB", published in the November/December 2009 issue.

The MATLAB xUnit package raised the visibility of unit testing tools in MATLAB, and its popularity helped make the case for putting something like it in MATLAB. At the same time, our testing tools team was looking to modernize our testing infrastructure. They wanted to take advantage of the latest test framework design principles, and they wanted to decouple the testing machinery from the rest of our complex systems for building and releasing products. So an idea was born: let's make a test framework that can stand on its own, that can test our own software, that can test customer code, and that we can ship in MATLAB!

And now, here it finally is!

Here are a few examples that I've taken from the documentation to illustrate. The first example shows how to write a couple of tests for a hypothetical function called quadraticSolver.

classdef SolverTest < matlab.unittest.TestCase
    % SolverTest tests solutions to the quadratic equation
    % a*x^2 + b*x + c = 0

    methods (Test)
        function testRealSolution(testCase)
            actSolution = quadraticSolver(1,-3,2);
            expSolution = [2,1];
            testCase.verifyEqual(actSolution,expSolution);
        end
        function testImaginarySolution(testCase)
            actSolution = quadraticSolver(1,2,10);
            expSolution = [-1+3i, -1-3i];
            testCase.verifyEqual(actSolution,expSolution);
        end
    end

end

If you need to define setup and teardown methods for your test cases, here's how you do it. (I've just shown the relevant portion of the entire test file.)

properties
    TestFigure
end

methods(TestMethodSetup)
    function createFigure(testCase)
        %comment
        testCase.TestFigure = figure;
    end
end

methods(TestMethodTeardown)
    function closeFigure(testCase)
        close(testCase.TestFigure);
    end
end

Someone asked me just this week about enhancing MATLAB xUnit to provide for setup and teardown methods that get executed just once for all the methods in a test file, instead of being executed once for every individual test method. MATLAB xUnit does not have this capability, but the new unit test framework in R2013a does. A class-level setup method is identified by using the TestClassSetup method attribute, like this:

methods (TestClassSetup)
    function doSomethingBeforeAllTestMethodsAreExecuted(testCase)
        disp('Hi, Mom!')
    end
end

There are lots of new capabilities in this framework. A little birdie told me that more information about matlab.unittest may appear pretty soon in Loren's blog. For now, though, I'd like to point you to the overview video and to the documentation.

That brings me back to MATLAB xUnit and its fate. Well, this little package is entering its "retirement phase." I imagine it will remain on the File Exchange for quite a while because it can take a long time for the user community to adopt a new release, and also because there's a lot of customer-written code out there that uses it. However, I do not plan to work on it anymore. Our testing tools team is an excellent group of engineers, and they can move matlab.unittest forward better and faster than I could ever do with my little side project.

So, if you're interested in unit testing and you get your hands on MATLAB R2013a, please give it a try.

Get the MATLAB code

Published with MATLAB® R2012b

Published with MATLAB® R2012b