On Apr 8, 2010, at 2:58 AM, Adam Heath wrote:
Stuff in framework/base is loaded automatically by framework/start, by
reading foo.properties file.
The reason the base metrics are invalid when run-tests is run, is not
because no test cases are run in base, but because there are 2
classloaders, both with cobertura active, and at shutdown, both
classloaders try to write to the same file, and corruption ensues. I
haven't felt the need to track it down, because base has bare tests
that give coverage.
Plus, actually fixing it would require me ripping framework/start,
base/src config/component/container logic into pieces.
Hey Adam, this is not what my results have shown. When I execute the
tests in our current trunk there are 216 tests executed (from the
JUnit reports) and I get code coverage on UtilValidate based on my
initial comment in the other thread "Here is my question -- when
looking at the reports it showed 100% line code coverage in
UtilValidate (for example) but this was for 111 lines. Clearly this
class has many more lines than that, and when I opened it up I saw
that large portions of it were not marked green or red in the report.
What gives? :)"
Now, if I decide to explicitly load the base component (and fix the
test def) two things happen. 1) My JUnit test report now reports 269
tests being executed and "basetests" appears in the classes on the
left drilling in shows 53 tests here (216 + 53 = 269). 2) when I run
the Cobertura report and drill down into UtilValidate it now shows 23%
line coverage (111/477 lines) and the class is properly marked green/
red.
I really think that our current builds are not executing your base
tests and there is actually not a problem with how the cobertura is
collecting its coverage metrics, the problem is really
TestRunContainer creates a JunitSuiteWrapper who asks
ComponentConfig.getAllTestSuiteInfos and this implementation uses
getAllComponents() which serves up the static map of configs which are
initially populated from the component-load.xml.
If we agree to that then I can propose a solution to ensure a
ComponentConfig instance exists for "base" but avoids parts of the
component load that we are not interested in but does perform things
we are interested in (see current ComponentConfig constructor -
classpathinfos vs. test suite infos).
