Test for Apex class that creates a custom field

Question

I have an apex class that creates a custom field on an sObject via an HttpRequest and I'm not sure how to write a test for this because one of the things I need to test is that the field has the correct value, so a mock or a bypass won't work. I can't get enough code coverage for this class if I exclude the web service call. Not sure where to go with this.

This is the request portion of the class in question:

public class RollupFieldCreator {

  @future(callout=true)
  public static void createRollupField(String fieldName, String description) {
      String fieldApiName = fieldName.trim().toLowerCase().replace(' ', '_') + '__c';

      if (!Schema.SObjectType.Asset.fields.getMap().keySet().contains(fieldApiName)) {
          String objectApiName = 'Asset';
          String toolingApiEndpoint = '/services/data/v41.0/tooling/sobjects/CustomField/';

          HttpRequest createField = new HttpRequest();
          createField.setHeader('Authorization', 'Bearer ' + UserInfo.getSessionId());
          createField.setHeader('Content-Type', 'application/json');
          createField.setEndpoint(URL.getSalesforceBaseUrl().toExternalForm() + toolingApiEndpoint);
          createField.setMethod('POST');
          String fieldDef = '{"Metadata" : {'
              + '"type" : "Text", "description" : "' + description
              + '", "inlineHelpText" : "", "precision" : null, "label" : "' + fieldName
              + '", "length" : 255, "required" : false}, '
              + '"FullName" : "' + objectApiName + '.' + fieldApiName + '"}';
          createField.setBody(fieldDef);
          Http httpInstance = new Http();
          HttpResponse response = httpInstance.send(createField);
          System.debug(response);
      }

Answer 1

AppExchange apps that modify production (e.g. deploying new fields or code) use the Metadata API, not the Tooling API. The Tooling API is intended for development purposes. You will need to write your code in a way that uses the Metadata API instead. You can see the source code for Rollup Helper to see how it is done in Apex Code; this package also demonstrates code coverage as well for such an app.

Answer 2

The normal way to add fields is to include the new field in the new managed package version. (The same also applies where e.g. the Ant deploy task is used.) Typically multiple other components will change at the same time:

• Apex code if the new field is important to the Apex logic of the managed package
• Object layouts
• Any profiles or permission sets also in the package

Making all these changes via the Metadata API would be painful and a new install will update everything fully automatically.

Things are not so good for version upgrades though as layouts will not automatically change as they are assumed to have perhaps been locally manually edited. But in real upgrades, typically locally created layouts and profiles or permission sets will be in use. Manual instructions are normally provided so customers can edit those as only the customer will know their exact use and whether or not to include the new field. In general, upgrades are a painful area that can't be fully handled by automation. So I suggest to not try (or find some magical 3rd party product that handles all the problems).

Answer 3

To answer more directly the question of how you unit test this, the answer is that you can use mocks and the Stub API.

You say: I can't get enough code coverage for this class if I exclude the web service call.

And also you say: one of the things I need to test is that the field has the correct value, so a mock or a bypass won't work

The thing is, you can't actually test the end-to-end behaviour because your unit tests cannot modify the org itself. So you can only assert against the things that are allowed to happen in unit tests.

The method you have pasted here can totally work with a mock, no problem. You can't test that it actually created the metadata of course. But suppose you decompose this @future method into a non-future method that returns whether the HTTP request was successful, and a future method that calls it. Now you can get coverage on the non-future method and assert it returned the right value (provided by your mock class), and you can get coverage on the one-line future method even though there's nothing to assert.

If you have code that you absolutely cannot cover unless it can definitively tell you that a field was created, then what you'd need to do is outsource the question of whether the field exists to a helper class. Then use the Stub API to inject a mock of that class into the class you're trying to cover, so when it checks if the new field exists (it doesn't), it gets a fake yes back.