I have a custom object with a formula field that references a couple other fields on the object. The class I've written my test class for requires the formula field, which it uses in a SOQL query. Problem is, rather than populating, the formula field remains null, causing the test to fail.

This issue has come up before, and the accepted solution on other posts is to simply query the formula field on the test record before triggering your actual code. But I've tried this and it doesn't work!

Here's the relevant code from my test class ('Time_Period_c' is the formula date field that uses 'Month_c' and 'Year__c'):

        Sales_vs_Budget_Reporting__c sRec1 = new Sales_vs_Budget_Reporting__c(Business_Unit__c = 'IP',
                                                                          Month__c = 'March',
                                                                          Year__c = '2014',
                                                                          Product_Group__c = 'Public Workshop',
                                                                          Record_Type__c = 'Closed Won',
                                                                          Salesperson__c = '00580000001rWsQ');

        insert sRec1;

        Sales_vs_Budget_Reporting__c pop1 = [SELECT ID, Time_Period__c FROM Sales_vs_Budget_Reporting__c Where ID =:sRec1.ID];


Then I run the starttest which calls my class (its a scheduled class not a trigger), which also happens to query the formula field and the records. But that system.debug call returns NULL.

What's the deal?


Your system.debug is outputting sRec1.Time_Period__c when it should be outputting pop1. Time_Period__c.

If that is a mistake in the debug output only and not in the test, and the test data is correct, then the other explanation would be that your test is demonstrating a bug in your formula.

PS Probably not related to this problem, but if your real test code has a hard-coded Salesperson__c ID that should be replaced by the ID of an object inserted by the test.

  • Your answer highlights the thing I had forgotten, that 'sRec1', aka the variable object I declared in the test, is not actually tied to the record created in salesforce after the dml statement. My system.Assert statements also tested against sRec values, as opposed to a SOQL query of the actual record, which is why my test wasn't passing. – smohyee Mar 13 '14 at 21:02
  • As to your PS, I'm not clear on why that's necessary, if the Sandbox copies users from Production as part of metadata, I shouldn't have to create a test user, should I? – smohyee Mar 13 '14 at 21:03
  • 2
    You are probably right that it will work. Avoiding "magic" numbers generally leads to clearer code, in this case the insert of a named object; imagine in a years time when someone else has to work on your code which is clearer. Or would something break in this test (or another test) if the User is deactivated? Or might you want to use this code in a completely different org in the future? Generally relying on SeeAllData=true leads to fragile tests. But it is you and your team's choice. – Keith C Mar 13 '14 at 21:35
  • Fair point. Funny thing is I didn't have to use SeeAllData=true. I think maybe users count as metadata when it comes to Apex? After all, they are copied over in dev sandboxes, unlike most table records. – smohyee Mar 14 '14 at 22:18
  • Interesting about User - thanks for mentioning it. – Keith C Mar 14 '14 at 22:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.