Hi Aaron,

A couple of quick sanity-check level questions:

(1) It's not clear to me that workspaces always work as intended on windows systems when no root is specified and thus the drive letter is part of the path. Is it possible that this problem goes away if the workspace root is correctly specified?

(2) The sensor data in your raw data map appears to be missing the fileName attribute, indicating a pre-evolutionary form of Coverage SDT and/or JBlanket sensor. It seems to me like your sensor should be sending the fileName attribute and it's not. Invoking the workspace mapper in this kind of analysis introduces another source of error.

At least for the purposes of debugging, it would be good to check the behavior when (a) the workspace root is configured and (b) the sensor data includes the correct file path. Is that possible?

Cheers,
Philip

--On Thursday, August 17, 2006 6:40 PM -1000 Aaron Kagawa <[EMAIL PROTECTED]> 
wrote:

Philip,

I need some help debugging an issue in the DailyProjectCoverage2.  Here is how 
to
reproduce it:

1) Rename TestDailyProjectCoverage2.brokenTestProjectCoverage2() to
TestDailyProjectCoverage2.testProjectCoverage2().
2) Run the unit test and it _should_fail.  If you are running in Eclipse you 
should see
the following output.

[CoverageRawDataMap for TestDailyProjectCoverage2 on 08-Jan-2004
 JBlanket
C: 1077800628000
    [fileName, , uncovered, 5, runTime, 1077800628000, misc, , granularity, 
method,
tool, JBlanket, covered, 4, className,
org.hackystat.stdext.activity.analysis.activetime.TestActiveTimeTrend, tstamp,
1073568438246, pMap,
000400004misc0000000009className00069org.hackystat.stdext.activity.analysis.activetime.
TestActiveTimeTrend]
    [fileName, , uncovered, 3, runTime, 1077800628000, misc, , granularity, 
method,
tool, JBlanket, covered, 3, className,
org.hackystat.stdext.activity.analysis.projectactivetime.TestProjectActiveTime, 
tstamp,
1073568438248, pMap,
000400004misc0000000009className00078org.hackystat.stdext.activity.analysis.projectacti
vetime.TestProjectActiveTime]
    [fileName, , uncovered, 2, runTime, 1077800628000, misc, , granularity, 
method,
tool, JBlanket, covered, 2, className,
org.hackystat.stdext.common.selector.interval.DayInterval, tstamp, 
1073568438305, pMap,
000400004misc0000000009className00057org.hackystat.stdext.common.selector.interval.DayI
nterval]
    [fileName, , uncovered, 5, runTime, 1077800628000, misc, , granularity, 
method,
tool, JBlanket, covered, 8, className,
org.hackystat.stdext.common.selector.interval.IntervalSelector, tstamp, 
1073568438309,
pMap,
000400004misc0000000009className00062org.hackystat.stdext.common.selector.interval.Inte
rvalSelector]
    [fileName, , uncovered, 0, runTime, 1077800628000, misc, , granularity, 
method,
tool, JBlanket, covered, 4, className,
org.hackystat.stdext.common.selector.interval.IntervalUtility, tstamp, 
1073568438310,
pMap,
000400004misc0000000009className00061org.hackystat.stdext.common.selector.interval.Inte
rvalUtility]
    [fileName, , uncovered, 1, runTime, 1077800628000, misc, , granularity, 
method,
tool, JBlanket, covered, 1, className, 
org.hackystat.stdext.project.ProjectException,
tstamp, 1073568438390, pMap,
000400004misc0000000009className00045org.hackystat.stdext.project.ProjectException]
    [fileName, , uncovered, 0, runTime, 1077800628000, misc, , granularity, 
method,
tool, JBlanket, covered, 4, className,
org.hackystat.stdext.test.HackystatCommandUnitTest, tstamp, 1073568438534, pMap,
000400004misc0000000009className00050org.hackystat.stdext.test.HackystatCommandUnitTest]
    [fileName, , uncovered, 2, runTime, 1077800628000, misc, , granularity, 
method,
tool, JBlanket, covered, 0, className,
org.hackystat.stdext.test.HackystatTestException, tstamp, 1073568438535, pMap,
000400004misc0000000009className00048org.hackystat.stdext.test.HackystatTestException]
    [fileName, , uncovered, 0, runTime, 1077800628000, misc, , granularity, 
method,
tool, JBlanket, covered, 4, className, org.hackystat.stdext.test.Parameters, 
tstamp,
1073568438536, pMap,
000400004misc0000000009className00036org.hackystat.stdext.test.Parameters]
    [fileName, , uncovered, 0, runTime, 1077800628000, misc, , granularity, 
method,
tool, JBlanket, covered, 3, className, org.hackystat.stdext.test.TestParameters,
tstamp, 1073568438537, pMap,
000400004misc0000000009className00040org.hackystat.stdext.test.TestParameters]
]
accessing getNumCovered()
[CoverageFilePatternCache for TestDailyProjectCoverage2 08-Jan-2004 JBlanket
<FilePattern: C:\**> method numcovered:33 numuncovered:18
]
topLevelWorkspace=C:\work\hackyStdExt\
topLevelWorkspaceName=C:
metricValue=33
topLevelWorkspace=C:\svn\
topLevelWorkspaceName=C:
metricValue=33
topLevelWorkspace=C:\cvs\
topLevelWorkspaceName=C:
metricValue=33
accessing getNumUncovered()
[CoverageFilePatternCache for TestDailyProjectCoverage2 08-Jan-2004 JBlanket
<FilePattern: C:\**> method numcovered:33 numuncovered:18
<FilePattern: **> method numcovered:99
]
topLevelWorkspace=C:\work\hackyStdExt\
topLevelWorkspaceName=C:
metricValue=18
topLevelWorkspace=C:\svn\
topLevelWorkspaceName=C:
metricValue=18
topLevelWorkspace=C:\cvs\
topLevelWorkspaceName=C:
metricValue=18
numCovered=99
numUncovered=54


Notice the 99 actual value is exactly 3 times the expected value.  My guess is 
that the
problem is from the 3 workspaces within the project.  Note that there seems to 
be no
workspace root.  So, the three workspaces (C:\work\hackyStdExt\, C:\svn\, 
C:\cvs\) have
the same top level workspace (C:\).  thus the following algorithm in the
CoverageFilePatternCache.updateCacheWithWildCards() process the same toplevel 
workspace
three times (which could be incorrect or correct depending on how you look at 
it).

    // Case 2: FP is wildcard, G is not.
    if ((filePattern.equals( this . wildCardFilePattern))
        && !granularity.equals( this . wildCardGranularity)) {
      // Iterate over top-level workspaces in this project.
      for (Iterator i = this . project .getWorkspaceSetIterator(); i.hasNext(); 
) {
        Workspace topLevelWorkspace = (Workspace)i.next();
        System.out .println( "topLevelWorkspace=" +
topLevelWorkspace.getCanonicalPath());
        String topLevelWorkspaceName = 
topLevelWorkspace.getTopLevelWorkspaceName();
        System.out .println( "topLevelWorkspaceName=" + topLevelWorkspaceName);
        FilePattern topLevelFilePattern = new FilePattern(topLevelWorkspaceName 
+
"/**");
        // Get the size value for the top-level file pattern and this g.
        long metricValue = this .getCoverageMetricValue(topLevelFilePattern,
granularity,
            metricName);
        System.out .println( "metricValue=" + metricValue);
        // Update the cache for ["**", g, m] We always want a cache hit for a 
wild card.
        this .incCache(filePattern, granularity, metricName, metricValue);
      }
    }

It seems to me that if we want to change "<FilePattern: **> method numcovered:99 
" to
"<FilePattern: **> method numcovered:33", then we would have to put the toplevel
workspaces into a Set to make sure we only process unique top level file 
patterns.

Anyway, let me know what you think.  The good news is that if it does get 
fixed, then
the unit test will pass.

Thanks, Aaron

Reply via email to