<html dir="ltr"><head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaTempEditStyle"></style><style title="owaParaStyle"><!--P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
--></style>
</head>
<body ocsi="x">
<div style="FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZE: 13px">
<div></div>
<div dir="ltr"><font color="#000000" size="2" face="Tahoma">We discussed coverage metrics in the context of iMesh/iMeshP unit testing.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">One useful metric is of course function count. However, many functions can be</font></div>
<div dir="ltr"><font size="2">c<font face="tahoma">alled with a variety of arguments including arguments that can drive the interfaces</font></font></div>
<div dir="ltr"><font size="2" face="tahoma">into error conditions and so function count alone can wind up not providing clear</font></div>
<div dir="ltr"><font size="2" face="tahoma">coverage metric for testing.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">We observed that routinely measuring coverage in the same way we routinely</font></div>
<div dir="ltr"><font size="2" face="tahoma">run tests and report results is probably NOT as essential as doing a focused</font></div>
<div dir="ltr"><font size="2" face="tahoma">gcov-like analysis as testing codes are developed and evolve.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">With the exception of iMesh reference implementation, existing iMesh/iMeshP</font></div>
<div dir="ltr"><font size="2" face="tahoma">implementations generally include a combination of some other product (e.g.</font></div>
<div dir="ltr"><font size="2" face="tahoma">FMDB, MOAB, GRUMMP) with an ITAPS interface wrapper bolted onto it. To</font></div>
<div dir="ltr"><font size="2" face="tahoma">adequately measure gcov-like coverage if ITAPS interfaces in this setting, we</font></div>
<div dir="ltr"><font size="2" face="tahoma">could take the following appraoch...</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">For any implementation, we identify the handful of source files were the ITAPS</font></div>
<div dir="ltr"><font size="2" face="tahoma">interface </font><font size="2" face="tahoma">wrapper code exists. Then, that wrapper code is prepared as necessary</font></div>
<div dir="ltr"><font size="2" face="tahoma">for gcov and the gcov analysis is performed ONLY on those relevant files. In this</font></div>
<div dir="ltr"><font size="2" face="tahoma">way, we measure coverage of the ITAPS interfaces WITHOUT having the
</font></div>
<div dir="ltr"><font size="2" face="tahoma">whole of the underlying implementation substrate factor into the analysis.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">As Jason observed, you'd only need to do this analysis as the test code itself</font></div>
<div dir="ltr"><font size="2" face="tahoma">is developed and modified, but as implementations change.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">Mark</font></div>
</div>
</body>
</html>