4

I have a webapp which makes REST calls. This webapp is bundled with cobertura instrumented classes. From the REST resource, the public service APIs are invoked using reflection (This was done to overcome some class loading issues with OSGI).

Now there is an issue with the code coverage. When i generate the cobertura code coverage report, i see that the coverage is being captured till the resource and all the reflective public method calls are ignored in the coverage.

Is there a way where we can get the coverage for the reflective methods calls as well.

Please find the code sample below

          for (Method method : methods) {
            if (method.getName().equals("getAbc")) {
                abc= (List<Abc>) method.invoke(**service**, serviceContextInfo);
              return SomeUtil.getSuccessResponse(abc, serviceContext);
                }
            }

The coverage is not captured from the "method.invoke" which is the core service call. And again I can see the coverage in the SomeUtil class where the response is updated.

Note: This being an OSGI environment (apache felix), the method being invoked is in a different class loader than the place where it is invoked from.

Sampath
  • 41
  • 2
  • Need to understand if you are using any mocking and the testing framework. Please give some example codes. – Aninda Bhattacharyya Feb 10 '15 at 13:55
  • @AnindaBhattacharyya : As of now i am not using any mocking or testing framework. I am just accessing the deployed webapp trying to hit various APIs to see if the corresponding coverage is captured. – Sampath Feb 11 '15 at 04:02
  • @AnindaBhattacharyya:Please find the code sample below ' for (Method method : methods) { if (method.getName().equals("getAbc")) { abc= (List) method.invoke(**service**, serviceContextInfo); return SomeUtil.getSuccessResponse(abc, serviceContext); } } ' The coverage is not captured from the "method.invoke" which is the core service call. And again I can see the coverage in the SomeUtil class where the response is updated. – Sampath Feb 11 '15 at 04:15
  • Does it tell you that the block inside the conditional is covered, e.g., are you convinced that "abc = ...method.invoke(....))" is actually being executed? If not, are you sure that the "response update" doesn't happen someplace else in your code? – Ira Baxter Feb 11 '15 at 04:38
  • @IraBaxter: Yes i am sure that the "method.invoke()" is actually being executed. The response update is done only in SomeUtil and the response is returned properly. Also i can see the code coverage in the SomeUtil.getSuccessresponse() methood. – Sampath Feb 11 '15 at 06:29
  • Hmm. Not my tool... educated guess from here: I suppose "method.invoke" is a method inside a system class Method? Since Coberatura instruments byte code, presumably it won't instrument that one. But one would expect it to instrument the method (call it "foo") that got called... don't you have to tell Coberatura which classes to instrument? I assume you told it to instrument the class containing foo? – Ira Baxter Feb 11 '15 at 06:41
  • Yes, from my instrumented deployment artifact, I see that the class containing foo is instrumented. But i guess that because it is being invoked by reflection, cobertura is not being able to reach that part of the instrumented code for capturing the coverage. – Sampath Feb 11 '15 at 07:06
  • Should there be a way where i can configure cobertura to capture the reflective method invocations. Looks like currently it is ignoring those method invocations.. – Sampath Feb 11 '15 at 07:08
  • If "foo" is instrumented, how is that the instrumentation fails to collect data? Do you know what the instrumentation actually is (what does it do, specifcially)? – Ira Baxter Feb 11 '15 at 11:36
  • Inserting some additional code into the byte code to capture the date whenever control reaches that block. As you already mentioned, the instrumented code must be collecting the data. But at the point where the data is flushed to some output file, which is used for the report generation, the data collected in this block is not reachable and so is not seen in the generated reports. Please correct me if i am wrong. – Sampath Feb 11 '15 at 12:12
  • Apparantly this coverage data is written to a .ser file. You've read the warnings about getting the wrong .ser file(s?) at the Cobertura site? In particular, there is discussion about stale instrumentation, and deleting old instrumented/.ser files? [I don't know this is the cause, but the discussion so far suggests the instrumentation exists and is executed, so somehow the instrumentation data is getting lost]. – Ira Baxter Feb 11 '15 at 15:22
  • Yes i have read that and am taking care of deleting the old file before trying to generate a new one. Also made sure that the .ser file created by the deployment artifact and the ones in the respective modules are all created and used properly while being merged. – Sampath Feb 12 '15 at 07:22

0 Answers0