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
