Apex class Code Coverage stuck at 0% (No coverage data) after running test class

Question

I have two classes:

1. ClassA.cls - was generated from a WSDL some time ago. Currently on API v22.0 and hasn't been changed recently.
2. Test_ClassA.cls - calls a large number of constructors in ClassA to assist with overall app code coverage. Currently on v20.0 and hasn't been changed recently.

I've run the tests in Test_ClassA.cls via Setup > App Setup > Apex Classes > Class name > Run Test. The asynchronous test gets enqueued, run to completion and passes.

If I now return to the list of Apex Classes the Code Coverage column for this class still reports "0% (No coverage data)". Following that link shows no code coverage highlighting.

When I encountered this issue in the past I was able to "reset" the code coverage as follows:

• Use the "Clear Code Coverage" button on the Apex Classes page.
• Go to View Test History under Apex Test Execution and press "Clear Test Results"

I tried both of these steps but the class still shows no code coverage while I'm certain it previously had at least 75% coverage. Its 5000 lines long (size without comments 250,000), so it needed pretty good coverage to be included in the managed package.

Why isn't my code coverage result showing up?

If I run the Test_ClassA.cls via the Apex Api the RunTestsResult.codeCoverage comes back as null. I can see in the debug log that it did run to completion and pass all the assertions.

UPDATE: I tried creating the managed package again that includes ClassA and Test_ClassA. Coverage jumped up to 76%.

Answer 1

Update: 10th May: Salesforce have confirmed this is an issue and appears to be resolved in Summer'13.

Confirmed Platform Bug Reproduced I spent a good portion of the weekend trying to get coverage for a WSDL2Apex class myself. Eventually whittled it down to a bug in the platform. The bug currently resides around tests that only invoke methods on "inner classes".

This is the standard pattern for classes generated by WSDL2Apex of course. The bug extends to the point that not only is code coverage not captured, it excludes the whole class from being required for code coverage, which explains the package upload behaviour. I reproduced it in the following...

public class TestA 
{
      public TestA() { }

      public class TestB 
      {
          public Integer doSomething()
          {
              Integer x = 1;
              Integer y = x;
              return y;         
          }
     }  
}

@IsTest
private with sharing class TestATest 
{
    private static testmethod void testMe()
    {
        // Uncomment the line below to work around the lack of code coverage bug
        // TestA testAObj = new TestA();

        TestA.TestB testBObj = new TestA.TestB();
        System.assertEquals(1, testBObj.doSomething());
    }
}

Workaround is to edit your generated class and put in a constructor and then invoke this from each of your test methods. If your concerned developers will attempt to use it (not that it would be much good, you can put an Test.isTesting() assert in it). Once we see a for fix this (I've raised case 09233301), this workaround can be left in or removed.

I'll update this answer when I get a response and/or the bug listed publicly. Note we have tests that do cover WSDL2Apex classes from the past, so this to me confirms this was at one point needed and is a regression. I did ponder if it was related to just WSDL2Apex generated classes only at first, which was starting to make sense, since they are none functional and system generated, shame...

Pattern for Generating 100% Coverage on WSDL2Apex Generated Classes. This is something I plan to blog about next weekend, but if your interested in taking a look at an approach I've used (irrespective of this issue) you can take a look at this. I'll update this answer when I do.