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

[Philip Johnson]

Hi Aaron,

You might want to look at the DailyProjectFileMetric test class to see if 
it provides any insights.   From my experience doing this for FileMetric, 
it's not necessarily the case that you want strict backward compatibility. 
For example, you might want to require that the fileName field be nonempty 
for the upgraded version.

Similarly, if the test data in the Coverage SDT does not contain a fileName 
field, then it might make things simpler and better to add the fileName 
field value.

Let me know if this makes sense to you.  My view is the workspace mapping 
approach was an interesting approach to evaluate, but on balance it was the 
wrong direction and it's OK to move forward with these redesigns and assume 
that data like the fileName will be present.  For example, it makes 
debugging way easier, since you don't have to make sure that there's 
FileMetric data available that corresponds to the class name.

Cheers,
Philip

--On Friday, August 18, 2006 2:18 PM -1000 "(Cedric) Qin ZHANG" 
<[EMAIL PROTECTED]> wrote:

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.anal
ysis.activetime.> TestActiveTimeTrend]

    [fileName, , uncovered, 3, runTime, 1077800628000, misc, ,

granularity, method,

tool, JBlanket, covered, 3, className,


org.hackystat.stdext.activity.analysis.projectactivetime.TestProjectAct
iveTime, tstamp,

1073568438248, pMap,


000400004misc0000000009className00078org.hackystat.stdext.activity.anal
ysis.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.select
or.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.select
or.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.select
or.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.Proje
ctException]>     [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.Hackysta
tCommandUnitTest]>     [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.Hackysta
tTestException]>     [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.Paramete
rs]>     [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.TestPara
meters]> ]

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