I tried running this on the SensorBase, and it didn't complete the
unit tests. The Agitar auto-JUnit runner bombs with our unit tests,
even though our unit tests run fine using the regular Eclipse JUnit
interface.
For sensorshell I also had bogus JUnit errors, but got a 1.6% of
CRAP.
Kind of a cool metric, actually. The problem I see with Agitar's
implementation is (a) it's only supported in Eclipse and (b) it
requires their internal coverage, unit testing, and complexity
mechanism, which as we are noticing is not robust.
The calculation of CRAP is quite simple, so I think the way we should
proceed is to write a DPD CRAP analysis that computes it based upon
Coverage data and FileMetric data (where the FileMetric data includes
cyclomatic complexity, which would be included for example by
JavaNCSS reports.) That makes our calculation of the metric
independent of the environment (Eclipse) as well as the specific
coverage/complexity tool.
It also makes it easy for us to experiment with extensions to the
formula. For example, they talk about introducing dependency
information, which is a good idea. Once we have CRAP at the DPD
level, it's a very simple matter to augment the formula with
dependency data.
Maybe I can get a student next semester to work on a crappy master's
thesis.
Cheers,
Philip
--On October 6, 2007 10:45:30 PM -1000 Austen Ito
<austen.
...@gmail.com> wrote:
> Yay XmlData's methods have a CRAPpy percentage of 3.94%, which is
> below the 5% threshold mark of module crappiness. My work project
> must be really crappy because I couldn't get the report to show up
> after running the tool.
> austen
> On 10/5/07, Philip Johnson <john...@hawaii.edu> wrote:
>> This is simultaneously funny and serious:
>> The Code C.R.A.P. Metric Hits the Fan - Introducing the crap4j
>> Plug-in:
>> <http://www.artima.com/weblogs/viewpost.jsp?thread=215899>
>> We've just got to support this in Hackystat. JavaNCSS provides
>> complexity, and we can combine that with Emma coverage.
>> Crap Telemetry Streams?
>> Philip
|
