missing XFactory interning in test driver about test-driven-detectors4findbugs

[Grundlefleck]

Ack :)

Will take a look, no ETA at the moment though.

[Grundlefleck]

Hi @GrimmiMeloni I've taken a stab at surgically removing the necessary parts of FindBugs2.analyzeApplication. I have written a test which has a detector using XFactory to create a method. I did observe this being returned as an UnresolvedMethod, then change to MethodInfo once I made the appropriate interning calls.

Could you build a jar from HEAD to test?

I couldn't reproduce the problem with accessing super/subtypes. That's probably because I am less familiar with how to use XFactory in this way -- it's not what I tend to in custom detectors. There's a test case here: https://github.com/youdevise/test-driven-detectors4findbugs/blob/master/src/test/java/com/youdevise/fbplugins/tdd4fb/DetectorRunnerTest.java#L97 . Would you be able to tell me what I'm doing wrong, or any cases that I should cover? If you could share some of your example uses of XClass that would also be really handy.

[GrimmiMeloni]

Hi @Grundlefleck !

I pulled your change. It solves the problem for the class under test, as well as it's supertypes.
The problem that still remains, is that all classes touched by the one under test are not interned into the factory.

I have pushed an additional test into my fork. The commit is:

GrimmiMeloni@c6398cb#diff-a8816d1f4768a47ae5230a0defa5839cR120

I think what we are really lacking here, is the possibility to add more classes to the classpath. Right now, when we use the DetectorAssert, the call includes only the Class under test itself. This is contrary to the way the classpath is setup when findbugs is executed "for real", because I there I can provide a whole set of classes.

Basically the situation we now have, is the one that findbugs typically reports as "missing classfiles".

I could imagine several solutions.
Maybe it is already sufficient to setup the Aux-Classpath. I am not sure if this is already possible with the test harness? (cough documentation cough :) )

If that is not working (or possible), than the other option could be to add a possibility to add more than just the class under test to the classpath, maybe in form of a Collection of classes.

Third option could be to automatically resolve all classes referenced by the class under test. I am not sure if this is feasable though.

[Grundlefleck]

The way I intended it to be setup was that you ran your unit test with a classpath that contained all the classes you referenced. It gets all the files to analyse by looking up the java.class.path SystemProperty. So it's not intended just to put the class under test onto the classpath, if you run unit tests under Maven/Eclipse/etc, you should have your entire project and it's dependencies on the classpath. There may be a mistake in how that's achieved, or I may be misremembering, but that was the goal anyway -- you just pass your class under test to DetectorAssert, and it should Just Work.

Maybe it is already sufficient to setup the Aux-Classpath. I am not sure if this is already possible with the test harness? (cough documentation cough :) )

No, that's not available, I wanted to shield users from having to worry about it. Not adverse to allowing extra config where necessary, just want to get as close as possible to working out-of-the-box, so that option is open.

I'm not sure why it's not currently working. You can see the aux code base paths being added from the current classpath in this code. Maybe there is a mismatch between the classes added to the aux code base paths, and those that are used for interning. Thanks for the test case, will have a look :)