Recent changes to feature-requests

Provide source code

2005-01-25T12:17:02Z

Please provide a zip with the source code as download.
Thanks!

specific

2004-03-17T18:12:13Z

I don't know if this is already possible: can I make
Hansel return results for specific methods (in the file
being tested) only?

Production of an eclipse plugin

2004-02-20T09:57:58Z

Any plans to produce an eclipse plugin for Hansel?

Add Hansel to a Maven repository

2004-01-05T18:59:01Z

I'd love to see Hansel added to a Maven repository at
some point (sooner rather than later)... it would make
tracking it as a dependancy much easier.

If people are interested, I can help set up the build for
it. For more into on maven, see: maven.apache.org.

Improve legibility of "is never false" conditions

2003-06-20T13:47:34Z

I have problems with the textual conditions. Here are
some examples where I stumble:

[PRIMARY] branch expression 'columnsSQL != null'
is never false

[EXCEPTION] branch expression 'maxCycle >= 0'
is never false

[PRIMARY] branch expression 'it.hasNext()' is
never false

[PRIMARY] branch expression 'whereSQL != null' is
never false

[SECONDARY] branch
expression 'cfn.equalsSelects_test(cfn2)' is never false

With all of these conditions, I juggle them around in my
mind until I find what I have to test:

'columnsSQL != null' is never false - aha, you
mean 'columnsSQL == null' is never true - so I have to
test with columnsSQL == null.

'maxCycle >= 0' is never false - let's see: that means
maxCycle < 0 is never true, so I need a test case so
that maxCycle becomes -1 or something like that.

... etc.

Suggestions to improve the situation somewhat:

1. The "stringification" of conditions could provide two
texts, one for the positive and one for the negative
condition. The probe selects the first text if the branch
is not "true-covered"; or the second text if the branch
is not "false-covered".

The examples above would then read:

'columnsSQL == null' is never true

'maxCycle < 0' is never true

... or even:

Test missing such that 'columnsSQL == null'

Test missing such that 'maxCycle < 0'

A nice side-effect of this could be that for the !
operator, one just has to switch the two strings ...

2. One could also add more "intelligence" so that e.g.
the expression

a < b

results in the strings

[positive] a < b
[negative] a >= b

3. Suggestion 1. would make some conditions harder to
read, e.g.

'cfn.equalsSelects_test(cfn2)' is never false

would become

Test missing such that '!cfn.equalsSelects_test(cfn2)'

For cases like this, one could look at the "top operator"
(which would have to be sent to the probe with the
created strings). Then, a rule of thumb could be:

* If the top operator is ! (and maybe some other
negating operators), then use the "negative text" and
add "becomes false".

In the example above, the result would be

Test missing such that 'cfn.equalsSelects_test(cfn2)'
becomes false

4. As a last and unrelated suggestion, conditions with
variables could maybe be "resorted" better. Here is an
example:

[SECONDARY] branch
expression 'this.columns.length - 1 >= i' is never true

i <= this.columns.length - 1

i < this.columns.length

would be nicer ... but this would require to look
somewhat into the tree. ANTLR, BTW, has nice features
to find patterns in trees and "rewrite" a subtree which
matches a pattern (but only for its own parse treesm
AFAIK) ...

Add "probe categories"

2003-06-17T09:23:32Z

I now add the "probe categories" as a "formal feature
request".

I have implemented a first version and am quite happy
with it. Output of covering my complete ORMapping (190
classes) is appended as a file.

Remarks on output file:

1. Probe 7) shows the "grouping feature": There are
many more "runtime exception branch failures" - but only
this single one is printed.

2. Probe 29) shows how code is automatically
categorized as "EXCEPTION". The source code is:

if (maxCycle < 0)
{
throw new F2SException("More than 100 repetitions
of checkTree necessary - there might be an endless loop
here.\n" +
"Please check whether there is a
cycle of non-lazy associations!");
}

I dont want to test this right now, I must confess ...

3. Probes 52)...56) shows that all code in an exception
class is also automatically categorized as EXCEPTION
code.

4. Probe 83) shows two bugs - one in hansel, one in my
additions: The source code is

if (result.parent != obj)
throw new InternalError("parent != obj??");

First bug: Hansel outputs the condition wrong (see a
previous bug report).

Second bug: I did *not* go into the branch - still, I get
the message

83) Probe in "DirectFetchNode.java" line 157 Coverage
failure:
[...]
[ERROR] branch expression 'obj == null' must not
be false

However, this shows nicely what happens with ERROR
branches: Such branches should NOT be covered. (If
you really want to cover it, you have to add a category,
e.g.

"Hansel**EXCEPTION".toString();

in the branch).

Specifying coverage of complete packages

2003-06-17T09:02:31Z

I have implemented the following in my current "private
version" of hansel: You can specify

<pre>
testSuite ts = new CoverageDecorator(
UnitOfWorkTestKnot.class,
new Class[] { UnitOfWorkTestKnot.class,
UnitOfWorkTest1.class,
UnitOfWorkTest1PK.class,
UnitOfWorkTest2.class, ... },
new String[] { "com.media_saturn.ormapping.*",
"com.ourcompany.ormapping.descriptor.*",
"com.ourcompany.ormapping.fetchtree.*",
"com.ourcompany.ormapping.queries.*",
"com.ourcompany.ormapping.unitofwork.*",
"com.ourcompany.ormapping.updates.*",
},
new String[] { "solid.jdbc" },
true);
</pre>

where the parameters are:

* test class

* "root classes" where instrumentation starts

* packages or classes which are instrumented

(Why not just "prefixes"? Because I want to be able to
instrument all in package com.media_saturn.ormapping,
but NOT in packages below [as
com.media_saturn.ormapping contains a few utility
classes which I want to cover first alone]. This is not
possible with a simple prefix logic. Of course, I now lose
the possibility to specify "all classes that start with
Abc". But this is not really useful anyway, I think ...).

* excluded packages which are not loaded through
modifying class loader

* flag to indicate whether to exclude the default list of
packages.

----

The change required quite a lot of "parameter chaining"
through various ClassLoader classes. In the end, the
method "shouldInstrument" has the logic to decide
whether the class should be instrumented. Here is the
code of ModifyingClassLoader.shouldInstrument (it also
gets javaClass.getPackageName() explicitly):

<pre>
private boolean shouldInstrument(String
packageName, String name) {
for (int i = 0; i < classNames.length; i++) {
String e = classNames[i];
if (e.endsWith(".*"))
{
// e is a package name
if (packageName.equals(e.substring(0,e.length
()-2)))
return true;
}
else
{
// e is a class name
if (e.equals(name)) {
return true;
}

if (name.startsWith(e + "$")) {
return true;
}
}
}

return false;
}
</pre>

[The array where the strings are stored is still
called "classNames", because I implemented this as a
hack. It should be called coverPatterns or something like
that.]

For my large ORMapping, I like this feature quite much ...

---

Additional things connected with this one:

* It should also be possible to specify

"com.ourcompany.ormapping.descriptor.**",

[note the TWO asterisks!]: This would mean "instrument
this package and all packages below".

* The same logic should than also apply to the exclude
prefixes - i.e., they should not be prefixes, but

-- complete (top level) class names

-- packages

-- **-packages - i.e. "this package and all below"

CoverageDecorator calls suite()

2003-06-07T02:09:04Z

To use CoverageDecorator on existing set of unit tests I
wrote a separate file called CoverageTest.java, which
contains just a suite() and main() methods. Where
CoverageTest.suite() construct a set of
CoverageDecorators into a suite.

Why?
1. Allows me to run unit tests with or without coverage.
More often I use naked tests during development.
2. Tests do not have hansel dependency and can be ran
by people who has no hansel installed, just junit
3. This way I can add coverage testing to existing tests
without source modification.

It would be nice to further develop that approach
of "optional" coverage decoration. One step can be
reuse of suite() methods of Test classes.

Sometimes we need to decorate a test with another
decorators, like junit.extensions.TestSetup. In this
scenario it does not work CoverageDecorator, because
CoverageDecorator calls new TestSuite(testClass) to
construct a TestSuite. The same way it does not work
with non-standard TestCases, like
junit.extensions.ExceptionTestCase, because new
TestSuite() could not be constructed.

Alternatively it can invoke testClass.suite() by using
reflection. This way if test class has suite() method
already decorated they all would work together.

There are two caveats:
1. What if there is no suite() defined in test class. Then
we will can continue with new TestSuite().
2. What if suite() contains CoverageDecorator. We can
come to an infinite loop. One way to detect it is to set a
lock on test class object and check it before calling suite
()

The above approach can be also used with in-test class
coverage decoration, not only "optional". In that case
we can have two methods:
suite(), which can have other decorators and
coverageSuite(), which will be something like usual:
{
return new CoverageDecorator(testclass, new Class[]
{testee});
}
If someone need to run tests with coverage all the time,
they can use in main:
{
junit.textui.TestRunner.run(testClass.coverageSuite());
}
It should work transparently for all current users of
CoverageDecorator, but you can create a separate
class, like
org.hansel.CoverageDecoratorThatCallsSuite. It would
satisfy my needs equally. Thank you very much.

Constant boolean expressions should display as symbols

2003-05-27T08:24:39Z

When the following line of code:

'if(isValid(pieceToMove, newLocation, true))'

is reported as part of a message about a branch not
completely covered, as follows:

'!this.isValid(pieceToMove, newLocation, 1)'

I think it would be nice if this displayed 'true' instead
of '1', and likewise for 'false' of course.

Display Probe names

2003-04-16T05:31:31Z

JUnit report is using Test.getName() to fill out the report.
So by adding getName() method to org.hansel.Probe
class we can see information about each probe on JUnit
report. Current version displays "Unknown". See
uploaded modified source code.

Also, what do you think of using class name and line
number as a Probe name. This is more useful
information, than Probe extended class name.