Good questions. First off, I ported the old TestDailyProjectCoverage unit test to TestDailyProjectCoverage2. So, I think they should both pass (with the exception of this test case). So, this is not an issue with the sensor or anything like that. I'm using the same testdataset data that the old unit test was using.
>From what I know about (1), it seems that the createClientSideTestProject >creates a project with three workspaces and _no_ workspace root. From what I >can remember there is no way to specify a workspace root. Anyway, if (1) is >the problem the it should be addressed in createClientSideTestProject and not >in the DailyProjectCoverage2 implementation. Right, (2) is correct. I'm using the test data in the testdataset directoy within the hackySdt_Coverage. I don't think this is an issue as it should still function correctly. Anyway, the issue is whether the DailyProjectCoverage2 should provide the same results as DailyProjectCoverage, because currently it does not in this specific case. I still think the code that I have below isn't correctly implemented. thanks, Aaron ----- Original Message ----- From: Philip Johnson <[EMAIL PROTECTED]> Date: Friday, August 18, 2006 1:37 pm Subject: Re: Help with a problem in DailyProjectCoverage2 (new DPD design) To: Aaron Kagawa <[EMAIL PROTECTED]> Cc: [email protected] > 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 > > > > > > >
