A Pattern for Apex Test Code So You Can Forget About Required Fields


Yeah, yeah, yeah, just take me to the code.

I recently had the opportunity to start writing some code in a brand new org, which got me thinking about the best way to do test object creation. You know, that annoying problem where you need to generate an Account in a test class about 77 times. Here’s a pattern I came up with.

This method involves some overhead but it has the advantages of (1) allowing you to set defaults for certain objects so you don’t have to worry about them – for some objects create them with all defaults with just one line, and (2) a generic, repeatable pattern.

It’s based on an abstract class that implements the base operations using some generic sObject magic outlined here.

A lot of code in this post, bear with me.

(That's a basic version, for something more robust, look here.)

For each object you will use, you need to create a class that implements the abstract factory class.

Then, in your test code you would need to instantiate the factory for each object, and set values in the Map using setFieldValue.


NB: You will need to be careful about the Map (setFieldValue calls), since in all subsequent calls the values class variable will still contain its prior values. That could cause logic issues if you’re setting fields you didn’t intend to. The abstract class contains a clearFieldValues() method to clear it out if necessary.

Seems like.. That’s a Lot of Work For Not a Lot of Benefit?

No doubt, it’s wordy. But here’s why it’s worth it. The big benefit is that all your defaults/required fields are taken care of – if you had a required field on your Contact, the code would pre-fill it for you. Or, you can override the default by setting the value in the Map.

I created a custom metadata type that allows you to fill in defaults; if you look in the abstract class above, it calls a fillDefaults() method. This goes into the custom metadata and populates the required fields. For example, you can set the default Name for Accounts.

Comments

Post a Comment

Popular posts from this blog

Setting a DateTime to a Weekday in a Formula

This is one of those things that took way too long to sort out. WEEKDAY() is a great formula function, but it only works on Dates.  Our requirement was to set the value to three days from now, but only if the day is a weekday, and put it in a datetime field. Thinking it through, they wanted the result to come out as follows. Cases received on Monday are due Thursday (+3 days) Cases received on Tuesday are due Thursday (+3 days) Cases received on Wednesday are due Monday (+5 days, skipping 2 weekend days) Cases received on Thursday are due Tuesday (+5 days, skipping 2 weekend days) Cases received on Friday are due Wednesday (+5 days, skipping 2 weekend days) Cases received on Saturday are due Wednesday (+4 days, skipping 1 weekend day) Cases received on Sunday are due Wednesday (+ 3 days) WEEKDAY() returns  an integer value, where 1 is Sunday and 7 is Saturday. Therefore: CASE(WEEKDAY(TODAY()), 4,now()+5, 5,now()+5, 6,now()+5, 7,now()+4, now()+3 ) Since WEEKDAY() onl...
Read more

"Disjunctions not supported" - Why Custom Metadata and Flow Don't Mix

Salesforce has been focusing a lot on Flow recently, as they should. It splits the difference nicely between Process Builder and Apex code. We recently used Flow to implement what I'd expect is a common use case - when a record is created, lookup a value from a table and update the record. In this case, it's a light lead score we call a "fireball" value. This worked great since in most use cases we'd get one record at a time. But we found during Lead conversion, we would get a few records through at a time, which caused the process to break with a really odd error: Error Occurred: This error occurred when the flow tried to look up records: Disjunctions not supported. After some research it became clear that this is the error you get when you try to query a custom metadata table using an "OR" condition. But my Flow didn't use an "OR" condition in the metadata lookup. The answer was lurking in this obscure documentation: When you define mult...
Read more

Update Knowledge Articles in Bulk

Image
Recently we had a big Knowledge Centric Support (KCS) initiative where we generated a ton of Articles for use in a Community. (We're still on Classic Knowledge.) Problem is, some users forgot to tick the "Customer" box when creating the Articles. So those articles didn't appear to external users in the Community. You can update these Articles in bulk, but you need to use a few obscure hooks in Apex. This method will create a draft of the Article, update the Knowledge Article Version, and then re-publish without creating a new Version. The following code will update the 'IsVisibleInCsp' flag for a single Article specified in the 1st query, which will make it visible to Customers. Here's a bulkified version. This is heavy on the CPU so I run it 10 at a time. When going over these in bulk, you might run into a situation where there is an existing draft of an article that has been previously published; i.e., it's actively being updated. In t...
Read more