I’m toying with the idea of adding a “unit test” custom object to apex-lang and I’d really like to know your thoughts. If possible, please read details below and leave a comment with your feedback.
My utopian vision for apex-lang is that it’s unit tests would succeed in any salesforce org capable of executing apex code. I’ve taken great care to make the unit tests as portable as possible; however, one area where this falls short is unit tests which must do DML. Those unit tests exercise the generic SObject handling methods and per the widely accepted pattern of creating data versus querying for it, they create records -> usually on Account or Contact. The problem with this approach of course, is these unit tests will fail when a required field is added to objects like Account or Contact.
Which brings me to my idea: inclusion of a custom object in apex-lang whose sole purpose is make unit tests which require SObject instances more predictable. The custom object would never be used in any practical sense other than in unit tests. I would also add as many fields as there are distinct field types; in other words, there’d be a string field, a date field, a multi-select picklist field and so on. In addition to making apex-lang unit tests more predictable, I think there’s a good use case for consumers of apex-lang who write generic SObject handling code. I do this often, like in the geocoding toolkit I created for a Cloudspokes challenge.
The first downside is I’d be violating another vision of mine for apex-lang: that it consist of apex code and apex code only. Probably not a big deal to throw in a custom object and I need to just get over it. The other downside I can think of is apex-lang would be burning a custom object. But it seems to me that most orgs have plenty to spare so that’s probably not a big deal either.
Thoughts?
Facebook
flickr
Linked In
Twitter