{"id":761,"date":"2016-10-24T18:30:04","date_gmt":"2016-10-24T18:30:04","guid":{"rendered":"https:\/\/blogs.mathworks.com\/developer\/?p=761"},"modified":"2016-10-28T17:17:42","modified_gmt":"2016-10-28T17:17:42","slug":"passing-diagnostics","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/developer\/2016\/10\/24\/passing-diagnostics\/","title":{"rendered":"Passing the Test"},"content":{"rendered":"

Last time<\/a> we saw that the new version 13 YAML output can provide a richer CI system experience because the diagnostics are in a standard structured format that can be read by a machine (the CI system) and presented to a human (you) much more cleanly.<\/p>

One thing I didn't mention is that the TAPPlugin (along with several other plugins<\/a>) now also supports passing diagnostics! It's as easy as an additional Name\/Value pair when creating the plugin:<\/p>

\r\nimport matlab.unittest.TestRunner<\/span>;\r\nimport matlab.unittest.plugins.TAPPlugin<\/span>;\r\nimport matlab.unittest.plugins.ToFile<\/span>;\r\n\r\ntry<\/span>\r\n    suite = testsuite('unittest'<\/span>);\r\n    runner = TestRunner.withTextOutput('Verbosity'<\/span>,3);\r\n    % Add the TAP plugin<\/span>\r\n    tapFile = fullfile(getenv('WORKSPACE'<\/span>), 'testResults.tap'<\/span>);\r\n    \r\n    runner.addPlugin(TAPPlugin.producingVersion13(ToFile(tapFile)), ...<\/span>\r\n        'IncludingPassingDiagnostics'<\/span>,true);\r\n    results = runner.run(suite)\r\ncatch<\/span> e\r\n    disp(getReport(e,'extended'<\/span>));\r\n    exit(1);\r\nend<\/span>\r\nexit;\r\n\r\n<\/pre>
With that simple change the output now includes not only the diagnostics from failing qualifications, but also the diagnostics from the passing qualifications as well. All of this information can now be stored in your Jenkins logs. Take a look:<\/p>
\"\" <\/p>
A couple things to note right off the bat. First, we can see that the tests I've zoomed in on here are passing. How do we know that without digging into the text? The colors tell us, look for the green!<\/p>
\"\" <\/p>
Second, we can actually see that some of these tests passed without any qualifications at all. Since we see no passing diagnostics, we can infer that there was no call to verifyEqual<\/tt><\/b> or assertTrue<\/tt><\/b> or anything. Is this expected? Not sure. There are definitely some times where a test does not need to perform any verification step, and just executing the code correctly is all the verification needed, but if I were a bettin' man I'd bet that most of the time there is an appropriate verification that can and should be done. This view makes such things more clear.<\/p>
\"\" <\/p>
Why might we want to include passing diagnostics? Usually we are most concerned with the test failures and we don't really need to provide any insight into passing qualifications? While this is definitely true, including the passing diagnostics may prove to be desirable in a number of ways:<\/p>
Diagnostics as proof<\/b> - Showing the passing diagnostics gives more information to the user, including even simply the test name. When called upon to prove the behavior of your software at any point in time (or any version of your SCM system), keeping a history of your test runs and how<\/i><\/b> they passed (as opposed to merely that<\/i><\/b> they passed) may prove valuable.<\/p>
Diagnostics to find root causes<\/b> - Unfortunately, test suites aren't perfect. They are very good defenses against the introduction of bugs, but sometimes bugs can slip passed their fortifications. However, when that happens you can look back into previously passing results and possibly gain insight into why the test suite didn't catch the bug. For example, in this example the test passes the verifyEmpty<\/tt><\/b> call, but if the correct behavior called for an empty double of size 1x0<\/tt>, these diagnostics would show that is was actually a 0x0<\/tt> cell array which was unexpected and would explain why the tests failed to catch the introduction of the bug.<\/p>
\"\" <\/p>
Diagnostics as specification<\/b> - Finally, including the passing diagnostics can provide self documenting test intent. This is particularly true if you leverage test diagnostics as the last input argument to your verification. The test writer can provide more context on the expected behavior of the test in the language of the domain, which can therefore act as a specification when combined with such reports. This is an important and oft misunderstood point. In order to support the display of passing diagnostics, when writing tests we should phrase diagnostics we supply in a way that does not depend on whether the test passed or failed. It should simply state the expected behavior instead. You can see in this example that:<\/p>
The vertices cell array should be empty by default.<\/pre>
is much better than:<\/p>
The vertices cell array was not empty by default.<\/pre>
A common mistake is to assume these descriptions only ever apply to failures when in fact they apply to both passing and failing conditions.<\/p>
\"\" <\/p>
What are the downsides of leveraging passing diagnostics? Really it boils down to performance and verbosity. Not everyone will want to wade through all the passing diagnostics to analyze the failures, and not everyone will want to incur the extra time\/space performance overhead that will come with including them. What about you? Do you find you need to analyze in more depth what happens in passing tests?<\/p>