{"id":2792,"date":"2022-04-12T04:31:04","date_gmt":"2022-04-12T08:31:04","guid":{"rendered":"https:\/\/blogs.mathworks.com\/developer\/?p=2792"},"modified":"2022-04-12T04:31:04","modified_gmt":"2022-04-12T08:31:04","slug":"always-start-with-a-failing-test","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/developer\/2022\/04\/12\/always-start-with-a-failing-test\/","title":{"rendered":"Failure is the first step to trying"},"content":{"rendered":"

The official guidance on test-driven development is to follow the red-green-refactor<\/a> cycle:<\/p>

  1. Write a test that fails.<\/li>
  2. Make it pass.<\/li>
  3. Refactor.<\/li><\/ol><\/div>

    But what’s the point in starting with a test that fails? To make sure you’ve written the right test! I encountered some unexpected behaviour recently that highlighted this point.<\/p>

    Imagine you have a Library<\/tt> that aggregates Items<\/tt>. An Item<\/tt> can be either a Book<\/tt> or a Film<\/tt>, but not both at the same time. If we create a Library<\/tt> in \"book mode\", it should initially contain an empty Book<\/tt>. If we create it in \"film mode\", it should initially contain an empty Film<\/tt>. Let’s start by writing a test to capture the book mode behaviour:<\/p>

    \nclassdef<\/span> tLibrary < matlab.unittest.TestCase\n\n    methods<\/span>(Test)\n\n        function<\/span> bookModeInitialisesToEmptyBook(testCase)\n            \n            lib = Library(Mode=\"book\"<\/span>);\n            \n            testCase.verifyEqual(lib.Items,Book.empty(1,0))\n            \n        end<\/span>\n        \n    end<\/span>\n\nend<\/span>\n<\/pre>
    Let’s run the test. We expect it to fail because Library<\/tt> doesn’t exist.<\/p>
    \"\" <\/p>
    We’ll skip over the steps of creating a blank class definition, the subsequent test failures due to a missing constructor with input arguments and a public Items<\/tt> property, and iteratively adding them in.<\/p>
    Instead, let's jump to the implementation of Library<\/tt> that makes our test pass:<\/p>
    \nclassdef<\/span> Library\n    \n    properties<\/span>\n        Items (1,:) Item = Book.empty\n    end<\/span>\n    \n    methods<\/span>\n        \n        function<\/span> lib = Library(nvp)\n            \n            arguments<\/span>\n                nvp.Mode (1,1) string {mustBeMember(nvp.Mode,[\"book\" \"film\"])} = \"book\"<\/span>\n            end<\/span>\n            \n        end<\/span>\n        \n    end<\/span>\n    \nend<\/span>\n<\/pre>
    We run the test and see that it passes:<\/p>
    \"\" <\/p>
    So far, so good. Now we write a test to capture film mode:<\/p>
    \nfunction<\/span> filmModeInitialisesToEmptyFilm(testCase)\n\n    lib = Library(Mode=\"film\"<\/span>);\n\n    testCase.verifyEqual(lib.Items,Film.empty(1,0))\n\nend<\/span>\n<\/pre>
    We run the test:<\/p>
    \"\" <\/p>
    And… it passes!?<\/p>
    Why is it passing? We can use the debugger to inspect lib.Items<\/tt> manually and see that it’s an empty Book<\/tt> and not an empty Film<\/tt>. After some investigation, we find that verifyEqual<\/tt> relies on isequal<\/tt> and isequal<\/tt> considers two empties of different classes to be equal under some circumstances.<\/p>
    Whether or not this behaviour of isequal<\/tt> is correct, the important point for us is that we’ve written the wrong test! Our implementation could have been wrong and we wouldn’t have known. We would have achieved full coverage<\/a> but our test would not have been contributing useful information.<\/p>
    We therefore need to rewrite our test to catch this issue:<\/p>
    \nfunction<\/span> filmModeInitialisesToEmptyFilm(testCase)\n\n    lib = Library(Mode=\"film\"<\/span>);\n\n    testCase.verifyEmpty(lib.Items)\n    testCase.verifyClass(lib.Items,?Film)\n\nend<\/span>\n<\/pre>
    Let’s run the updated test:<\/p>
    \"\" <\/p>
    The test now fails and we can continue with our implementation, confident that our test will only pass when our implementation is correct.<\/p>
    (The Name=value<\/tt> syntax for name-value pairs was introduced in R2021a<\/a>. It’s interchangeable with the classic (…,\"Name\",value)<\/tt> syntax.)<\/p>