[SalesForce] Partner Account ID-Lead Object

While it looks to be undocumented, formula fields do not appear to be supported by SOSL.

The search() call searches most objects (including custom objects) and text fields to which you have access. It does not search the following objects and fields:

• Any elements such as picklists that are defined as not searchable (searchable is false). To determine whether a given object is searchable, your application can invoke the describeSObjects() call on the object and inspect the searchable property in the DescribeSObjectResult.
• Number, date, or checkbox fields. To search for such information, use the query() call instead.
• Textarea fields, unless you use the ALL FIELDS search group.
• Attachment records associated with certain objects, such as Account, Contact, or Opportunity.

While triggers and apex sound like quite a lot of overhead, at this point it looks to be the only option to mimic formula field behavior to create a searchable field on your child records.

First, thank you, Ralph, for asking this question and putting yourself out there. As a matter of communication I don't mean to call you out on anything at all, but I want to give a detailed, (hopefully) thoughtful answer to a detailed, thoughtful question.

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?

As someone who'd asked the same question myself, I think I understand why you posted to Stack Exchange. However, I believe a better question is, "How can I make sure critical formula fields are tested properly to protect against unintended consequences?"

I believe you should want changes to formula fields to break Apex tests, especially when your app logic depends on those formula fields. Imagine having an Apex class to create the output that the formula field currently produces. In that case you're forced to write an Apex test for that other class, and in the app logic that you are writing you would rely on proper test coverage of the other class.

A formula field is simply another means of automating business logic. And just like other means, such as Apex, Visual Workflow, JavaScript, workflow rules or Process Builder, a formula field used as a critical automation component should have adequate test coverage.

So, regarding this idea:

Good test methods shouldn't break when administrators make changes.

I believe that good test methods should break when administrators (or developers) make changes that impact the app logic that you've implemented. I think this is the only way to sustainably work in a team environment with multiple admins and devs.

Recommendations

All that to say I support both recommendations from NSjonas and Bobby White.

... treat the Formula Field as though it were a stand alone class and ensure that you have adequate code coverage for all of the branches that are implicit in it.

-- Bobby White

I would recommend de-coupling the class with the actual instance of the object if possible. That way you can test the branch conditions individually by passing whatever value you want into the code.

-- NSjonas