I am using Clover to gather coverage data for test cases that run on our product code that is installed as a part of WebSphere Application Server (WAS). Some of these tests are true unit tests (and call the code being tested directly), but most make EJB calls into WAS to invoke product functions that require the server to be running. In general, this seems to work well (and in fact, it was this ability to handle multiple JVMs running the same instrumented code that drew me to Clover).
In order to handle the large quantity of code, we have broken up the coverage tracking into many pieces. Some are small (100-1000 elements, as reported by Clover)), while others are very large (around 450K elements). We are running a coverage build and test cycle once per week (occasionally sooner), and we save the reports so that we can observe trend data.
The problem is that we are seeing wide fluctuations in the coverage numbers reported from week to week. For example, we had one component that went from
%age classes Elements covered Total elements
5.3% 797 2,356 44,679
to
42% 797 18,768 44,695
while a different component went from
5.2% 115 522 9,981
to
35.9% 115 3,586 9,980
in the span of 5 days. The same tests were all run in both cases (we have the evidence on our CI server that shows the tests run were the same in both cases), and as you can see from the total number of elements, there were minimal code changes between the two.
In another case, we have a component where Clover report generation says that no coverage recordings could be found, but we can clearly see coverage recordings right next to the clover.db file.
How can we get the reports to be more predictable?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.