{"id":1083,"date":"2017-10-16T17:43:35","date_gmt":"2017-10-16T21:43:35","guid":{"rendered":"https:\/\/blogs.mathworks.com\/developer\/?p=1083"},"modified":"2017-10-17T10:18:57","modified_gmt":"2017-10-17T14:18:57","slug":"cobertura-code-coverage","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/developer\/2017\/10\/16\/cobertura-code-coverage\/","title":{"rendered":"We’ve Got You Covered"},"content":{"rendered":"

Coverage. It's all good. Health care coverage is good. Cell phone coverage is good. Even cloud coverage can provide a nice break from the intensity of the sun's rays sometimes. It should come then as no surprise that good code coverage also gives us that nice warm fuzzy feeling, like a nice warm drink on a cold day.<\/p>

...and often for good reason. Code coverage can help us see areas of our code that are not exercised in some form or another, and can be very helpful, in a good-friend-that-can-be-brutally-honest-with-you<\/i> sort of way. It can point out where we really need to add more testing. Once we react to our good friend's advice and add better testing, we are all the better.<\/p>

A quick aside to add some caution is in order. We (all) should remember that code coverage does not as much show what code is<\/i> covered as which code is not<\/i> covered. This is because seeing that a piece of code is covered says nothing about how it was covered, whether it was covered by a test specifically targeting that code or some incidental coverage, and there is no information as to whether the coverage verified the correct result in any way. Takeaway, use coverage to see areas of the code are not<\/i><\/b> tested. Don't fall into the trap and draw conclusions that covered code is bug free or is even remotely tested sufficiently.<\/p>

That said, it is a great tool if you have the right mindset about it, and when combined with testing and continuous integration it can help us ensure our testing is up to snuff.<\/p>

Good news! This just got a lot easier. We have had the CodeCoveragePlugin<\/a> for the unit test framework for some time, but it has produced a report that was more designed to be used in interactive MATLAB environments rather than CI system workflows. Now we have the option to produce our coverage into the Cobertura<\/a> format and benefit from things like the Cobertura plugin for Jenkins<\/a>.<\/p>

Let's continue with our (matrix'd) build from last time<\/a>, but add some coverage.<\/p>

\r\nimport('matlab.unittest.plugins.CodeCoveragePlugin'<\/span>);\r\nimport('matlab.unittest.plugins.codecoverage.CoberturaFormat'<\/span>);\r\n\r\ncoverageFile = fullfile(resultsDir, 'coverage.xml'<\/span>);\r\nrunner.addPlugin(CodeCoveragePlugin.forFolder(src,...<\/span>\r\n    'Producing'<\/span>, CoberturaFormat(coverageFile)));\r\n\r\n<\/pre>
Easy as pie. Now let's see what it looks like in our CI build:<\/p>
\"\" <\/p>
Oops! I forgot about the fact that other releases we are building against don't have the plugin:<\/p>
\"\" <\/p>
No biggie, we'll just need to wrap the installation of our plugin into the TestRunner with a version check. Let's put it into a function:<\/p>
\r\nfunction<\/span> addCoberturaCoverageIfPossible(runner, src, coverageFile)\r\n\r\nif<\/span> ~verLessThan('matlab'<\/span>,'9.3'<\/span>)\r\n    import('matlab.unittest.plugins.CodeCoveragePlugin'<\/span>);\r\n    import('matlab.unittest.plugins.codecoverage.CoberturaFormat'<\/span>);\r\n    \r\n    runner.addPlugin(CodeCoveragePlugin.forFolder(src,...<\/span>\r\n        'Producing'<\/span>, CoberturaFormat(coverageFile)));\r\nend<\/span>\r\n\r\nend<\/span>\r\n\r\n<\/pre>
and we can just call that function from our test running script:<\/p>
\r\ntry<\/span>\r\n    import('matlab.unittest.TestRunner'<\/span>);\r\n    import('matlab.unittest.plugins.XMLPlugin'<\/span>);\r\n    import('matlab.unittest.plugins.ToFile'<\/span>);\r\n\r\n    \r\n    ws = getenv('WORKSPACE'<\/span>);\r\n    \r\n    src = fullfile(ws, 'source'<\/span>);\r\n    addpath(src);\r\n    \r\n    tests = fullfile(ws, 'tests'<\/span>);\r\n    suite = testsuite(tests);\r\n\r\n    % Create and configure the runner<\/span>\r\n    runner = TestRunner.withTextOutput('Verbosity'<\/span>,3);\r\n\r\n    % Add the TAP plugin<\/span>\r\n    resultsDir = fullfile(ws, 'testresults'<\/span>);\r\n    mkdir(resultsDir);\r\n    \r\n    resultsFile = fullfile(resultsDir, 'testResults.xml'<\/span>);\r\n    runner.addPlugin(XMLPlugin.producingJUnitFormat(resultsFile));\r\n   \r\n    coverageFile = fullfile(resultsDir, 'coverage.xml'<\/span>);\r\n    addCoberturaCoverageIfPossible(runner, src, coverageFile);\r\n    \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\nquit('force'<\/span>);\r\n\r\n<\/pre>
Also, the MATLAB code is just one half of the equation. We also need to ensure the Jenkins Cobertura plugin is installed and that the build is configured to track coverage. Here we simply add it as a post-build action and we configure it to look in our results folder, looking for files named coverage.xml<\/tt>.<\/p>
\"\" <\/p>
Note that since we are running testing across multiple releases, and the earlier releases don't have the plugin, we also need to tell the plugin not to fail the build if there are no coverage files present. If we don't then the builds for all the earlier releases will fail because no Cobertura xml file will be found.<\/p>
OK, now we are in business. The build now passes across all releases:<\/p>
\"\" <\/p>
However, when we navigate to the R2017b build, we can see the coverage report:<\/p>
\"\" <\/p>
Digging in deeper we can then see where we need to add a test:<\/p>
\"\" <\/p>
The build now shows very clearly that we forgot to add a negative test. Let's remedy that! Here is the test I want to write:<\/p>
\r\nfunction<\/span> testInvalidInput(testCase)\r\n% Test to ensure we fail gracefully with bogus input<\/span>\r\n\r\ntestCase.verifyError(@() simulateSystem('bunk'<\/span>), ...<\/span>\r\n    'simulateSystem:InvalidDesign:ShouldBeStruct'<\/span>);\r\nend<\/span>\r\n\r\n<\/pre>
However, looking again at our source, I notice something horrible, we are not testable! As a reminder, here is the code for the simulator:<\/p>
\r\nfunction<\/span> [x, t] = simulateSystem\r\n\r\nspringMassDamperDesign; % Create design variable.<\/span>\r\n\r\nif<\/span> ~isstruct(design) || ~all(isfield(design,{'c'<\/span>,'k'<\/span>}))\r\n    error('simulateSystem:InvalidDesign:ShouldBeStruct'<\/span>, ...<\/span>\r\n        'The design should be a structure with fields \"c\" and \"k\"'<\/span>);\r\nend<\/span>\r\n\r\n% Design variables<\/span>\r\nc = design.c;\r\nk = design.k;\r\n\r\n% Constant variables<\/span>\r\nz0 = [-0.1; 0];  % Initial Position and Velocity<\/span>\r\nm = 1500;        % Mass<\/span>\r\n\r\nodefun = @(t,z) [0 1; -k\/m -c\/m]*z;\r\n[t, z] = ode45(odefun, [0, 3], z0);\r\n\r\n% The first column is the position (displacement from equilibrium)<\/span>\r\nx = z(:, 1);\r\n\r\n<\/pre>
...and for the design:<\/p>
\r\nm = 1500; % Need to know the mass to determine critical damping<\/span>\r\n\r\ndesign.k = 5e6;                  % Spring Constant<\/span>\r\ndesign.c = 2*m*sqrt(design.k\/m); % Damping Coefficient to be critically damped<\/span>\r\n\r\nclear m<\/span>;\r\n\r\n<\/pre>
Yikes! There is no way to get a bad value into the code in order to test it. As such currently the code is dead. If we want we could just remove the error condition because we know that the script produces the right format of the design. However, that would miss the point. The whole reason why we separated out the design from the simulation script is so that we could tweak the design and explore. We really want the simulateSystem<\/tt> function to be reusable across many different designs, so we should parameterize it proper. Then the software is much more testable, which is synonymous with flexible. To do this all we need to do is make the design script a function and accept it as an input to the simulation function:<\/p>
\r\nfunction<\/span> [x, t] = simulateSystem(design)\r\n\r\nif<\/span> ~isstruct(design) || ~all(isfield(design,{'c'<\/span>,'k'<\/span>}))\r\n    error('simulateSystem:InvalidDesign:ShouldBeStruct'<\/span>, ...<\/span>\r\n        'The design should be a structure with fields \"c\" and \"k\"'<\/span>);\r\nend<\/span>\r\n\r\n% Design variables<\/span>\r\nc = design.c;\r\nk = design.k;\r\n\r\n% Constant variables<\/span>\r\nz0 = [-0.1; 0];  % Initial Position and Velocity<\/span>\r\nm = 1500;        % Mass<\/span>\r\n\r\nodefun = @(t,z) [0 1; -k\/m -c\/m]*z;\r\n[t, z] = ode45(odefun, [0, 3], z0);\r\n\r\n% The first column is the position (displacement from equilibrium)<\/span>\r\nx = z(:, 1);\r\n\r\n\r\n\r\nfunction<\/span> design = springMassDamperDesign\r\nm = 1500; % Need to know the mass to determine critical damping<\/span>\r\n\r\ndesign.k = 5e6;                  % Spring Constant<\/span>\r\ndesign.c = 2*m*sqrt(design.k\/m); % Damping Coefficient to be critically damped<\/span>\r\n\r\n<\/pre>
Make a few test updates:<\/p>
\r\nfunction<\/span> tests = designTest\r\ntests = functiontests(localfunctions); \r\nend<\/span>\r\n\r\nfunction<\/span> testSettlingTime(testCase) \r\n%%Test that the system settles to within 0.001 of zero under 2 seconds.<\/span>\r\n\r\n[position, time] = simulateSystem(springMassDamperDesign); \r\n\r\npositionAfterSettling = position(time > .002);\r\n\r\n%For this example, verify the first value after the settling time.<\/span>\r\nverifyLessThan(testCase, abs(positionAfterSettling), 2);\r\nend<\/span>\r\n\r\nfunction<\/span> testOvershoot(testCase)\r\n %Test to ensure that overshoot is less than 0.01<\/span>\r\n\r\n[position, ~] = simulateSystem(springMassDamperDesign);\r\novershoot = max(position);\r\n\r\nverifyLessThan(testCase, overshoot, 0.01);\r\nend<\/span>\r\n\r\nfunction<\/span> testInvalidInput(testCase)\r\n% Test to ensure we fail gracefully with bogus input<\/span>\r\n\r\ntestCase.verifyError(@() simulateSystem('bunk'<\/span>), ...<\/span>\r\n    'simulateSystem:InvalidDesign:ShouldBeStruct'<\/span>);\r\nend<\/span>\r\n\r\n<\/pre>
...and now we should be in business. Let's check the build and the resulting coverage:<\/p>
\"\" <\/p>
\"\" <\/p>
Ah, that's nice. Let's call it a day.<\/p>
...but not before you check out Steve's new blog on deep learning<\/a>! The man is amazing. He's been a world class blogger on image processing for years, and now he's adding deep learning into his repertoire. He has even promised that he will keep the image processing blog going. What a guy! I'm looking forward to it, be sure to catch up he already has a couple posts here<\/a> and here<\/a>.<\/p>