1

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];

system.debug(sRec1.Time_Period__c);

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?

Improve this question

1 Answer 1

Reset to default
2

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.

Improve this answer
5
  • 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
    Commented Mar 13, 2014 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
    Commented Mar 13, 2014 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
    Commented Mar 13, 2014 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
    Commented Mar 14, 2014 at 22:18
  • Interesting about User - thanks for mentioning it.
    – Keith C
    Commented Mar 14, 2014 at 22:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .