Cleaner inner class test fixture pattern

I favor this inner class test fixture pattern for Apex unit tests where a set of related objects are required. It leverages Apex’s support for named parameters when concrete SObject types are created making the code self describing and quick to modify including when fields are added. (Patterns like builder typically need extra methods adding when new fields are added.) And rather late in the day I’ve noticed that the result of an assignment is the value assigned (as in languages like Java).

These two language features together allow this high signal-to-noise ratio fixture style where a single line initializes, assigns and inserts each object:

@isTest
private class OneTwoThreeTest {
    class Fixture {
        One__c one;
        Two__c two;
        Three__c three;
        Fixture() {
            insert one = new One__c(Number__c = 12.34);
            insert two = new Two__c(One__c = one.Id, String__c = 'Hello');
            insert three = new Three__c(Two__c = two.Id, Checkbox__c = true);
        }
    }
    @isTest
    static void test() {
        Fixture f = new Fixture();
        // ...
    }
}

Ant task that automates the installation of managed packages

PS Summer ’13 looks like it adds meta data support for managed packages so check that out first…

At ClaimVantage we deploy using a mixture of managed packages and source code. The development process for a customer can involve up to this many orgs:

  • one (or more) developer edition orgs that developers create the custom code in
  • a build org that the Jenkins continuous integration server uses to verify that the code committed to the version control system is deployable including 100% passing tests
  • a QA sandbox org that the customer’s QA team test in
  • a UAT sandbox org that the customer’s business users test in
  • the customer’s production org

And as we typically work in 2 week long iterations, over a few months of work for a customer many deployments get done to each of these orgs.

The source code can be pushed into orgs using the Ant tools provided by Salesforce. While it is not quick – typically it takes a few minutes – it requires no attention once started so you can get on with other work and check the outcome later.

But managed package installation unfortunately involves a multiple-page wizard with slow transitions between the pages even before the final asynchronous step. And Salesforce have not provided an API or any other tooling to allow this tedious button clicking to be eliminated.

So I am very grateful that my colleague Sinead Coyle has created an Ant task that automates the clicking via Selenium. She is now sharing this in the Google code project force-managed-package-installer. It allows the managed package installation or upgrade to be just another step in the Ant script ahead of the source code deployment.