Re: [HACKYSTAT-DEV-L] Help with a problem in DailyProjectCoverage2 (new DPD design)

[(Cedric) Qin ZHANG]

I can confirm (1). Apart from that, there are weird consequences (I 
cannot recall exactly) if you try to reuse project. Try not to use the 
same project names in TestDailyProjectCoverage and 
TestDailyProjectCoverage2.

Cheers,
Cedric

Aaron Akihisa Kagawa wrote:
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: HACKYSTAT-DEV-L@HAWAII.EDU

  
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