3

I've previously used the SOAP version of the Tooling API to run the following SOQL query to get the aggregate code coverage for an Apex class.

SELECT ApexClassOrTriggerId, ApexClassOrTrigger.Name, Coverage FROM ApexCodeCoverageAggregate where ApexClassOrTriggerId = '01p400000005cBjAAI'

I noticed that once I upgraded from v36.0 to v37.0 (Spring '16) of the Tooling API the Coverage stopped including the coveredLines and uncoveredLines. They were just null when checked in .NET code.

If I make the SOAP call directly I can see them coming back. enter image description here

Same with the equivalent REST API call. enter image description here

Why did they stop working in code?

4

Update for Winter `17 Patch 14.2.

This appears to be resolved as the coveredLines and uncoveredLines in the response are now in the "urn:tooling.soap.sforce.com" namespace.

Namespace changes


I suspect this is a bug in the Tooling API that was introduced in Spring '16.

If you diff the v36.0 to v37.0 Tooling API WSDL a number of elements changed namespace from tns: (xmlns:tns="urn:tooling.soap.sforce.com") to ens: (xmlns:ens="urn:sobject.tooling.soap.sforce.com")

For ApexCodeCoverageAggregate, it extends sObject which changed namespace. Also, a number of other elements on the complexType also changed (ApexClassOrTrigger, CreatedBy, LastModifiedBy). However, Coverage remained in the older tns namespace.

enter image description here

The SOAP response shows the problem. The Coverage is in the sf namespace (xmlns:sf="urn:sobject.tooling.soap.sforce.com") rather than the expected default namespace for the response (xmlns="urn:tooling.soap.sforce.com")

enter image description here

Raised as support case 14656682.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.