Are there any best practices out there for testing apex code that is driven by formula fields so that changes to the formula field formula don't break your test?
Good test methods shouldn't break when administrators make changes. While impossible, it's nice to get as close as possible to this ideal.
Formula fields make this tricky. In order to get a predictable (deterministic) result from your test you often need to ensure the formula field has a particular value.
One option is to have your test to "know" the formula field syntax, and setup the data to ensure you get a desired value in the formula field. Downside is now whenever that formula field changes, you're test breaks.
Another option is a
Test.isRunningTest() switch in your code that alters the logic code to bend around the formula. Downside is it's easy to write a test that gives you an all clear, but is broken for end user.
Neither of these is great, has anyone out there run into this and found something that works for them?
This obviously won't matter in a lot of cases, since formula fields don't really change much, but to give it some context, imagine the following scenario loosely based on a project I'm working on.
You've got a trigger that creates a project assignment record based on changes to a parent project record that lists who is on a project, for how long, and what their roles are. The project assignment has an end date field you need to populate. The logic to determine the end date is complicated, i.e. (if project end date is null, then project start date + 20, unless progress is greater than 50%, in which case it's project start date + 10), and the requestor expects there going to need to tweak it several times to get the end date right. So you create formula field, "Project Assignment End Date" to encapsulate the logic, and your trigger just looks at the formula field, doesn't have to worry about what the logic is, and the requestor can make changes without calling the developer in. It's working great, but now you need to write your test methods. How do you go about it so you have a test method that truly tests your code, but doesn't break the first time an admin makes a change?
An even better example would be using a formula field as configuration to drive code, in which case it becomes a must tests can't break on changes, and important that you can test that some version of the formula works.
SObjectFactoryutility that can create any object type and you just specify field/value pairs, but this sort of functionality forces us to diverge from that paradigm. The general
TestUtilsparadigm I've seen might require less of a shift.