Scott Gray wrote: > Hi Adam, > > Looking at the results my first impression is that the coverage is > under-reported. For example, the accounting component has quite a few > tests but no coverage is shown at all (except for the test package > itself). Possibly because there is lot of logic in simple methods but > I'm 100% sure java code is also run during the tests. > > But still a great start and something that will be immensely useful if > we can up the accuracy a bit.
Well, it doesn't, really. If you click thru to accounting.test, you'll see that there aren't really that many tests. And, upon further investigation, the lines after the runSync calls aren't run, due to some exception most likely. I'm not certian if this is do to my changes, or if the tests themselves are broken. I'm running a plain test run now to check that. Plus, there actually *is* line hits in accounting.invoice. Additionally, the way the classloaders are constructed is a bit odd. The bootstrap loader only has ofbiz.jar. The code then creates a classloader will *all* jars in base/lib, recursively. After the containers and components are started, yet another classloader is created, this time with proper libs and all other ofbiz-$foo.jar. Both of those classloaders update the java.class.path system property. This is a bug, as the instrumentation changes all ofbiz-$foo.jar into a new jar in /tmp, so the value of the property is different each time. Additionally, the second created classloader should not load the base component again, as that is sub-optimal. I'm thinking that component code should really move to start. Another bug, is that due to one of the above bugs, the first classloader is not instrumented at all. Since this is the classloader that contains framework/base, you don't see any line hits in the report.
