Avoiding triggers/flows on managed objects during Apex testing

Question

We are integrating with a managed package that our company bought. We've inserted a custom VF page with an apex controller into their UI and I'm now trying to test the controller. In the constructor it makes some SOQL queries with object ids passed to the page. The ids are of objects in the managed package.

As I understand, the standard approach is for the test to create all the data the controller would need. However, creating these objects appears to trigger all sorts of triggers and flows in the managed package, which expect other objects to exist, validates data, etc.

All I want is to make a simple mock of an object and fill in one or two fields, so that my controller can query them and move on. I'm not at all interested in the triggers and flows that are part of the managed package, I want to unit test just my controller. What's the proper way to do this?

Answer 1

With managed package integrations, sometimes you are forced to use seealldata=true in the test class. It is sometimes impossible to setup test data (due to limits) through the packages normal flow.

Seealldata=true is like a last resort. You then put a dependency on data being setup in the running org, properly and complete to the point that your customization can function as expected. But sometimes there is no better choice.

Alternative is to somehow create mock data in the package object directly using DML. Or create the mock data but don't insert with DML, but set the controller.objectVar to your temp record.

You may need changes in the controller to facilitate a workaround. That's the downside to seealldata=false in this situation (having to modify the real code just to get a test to operate).

It's a situation where "it depends" on many factors like risk, cost, quality etc. Best practices should be followed when best fit, this may fit or may not.

Answer 2

There's only one "reasonable" path: the ISV should build a global class that includes methods that you can use to correctly build all the required data. I don't think I've ever seen this done in a package, but it's not outside the realm of possibility. Try asking. Everything else is just a bad idea. However, sometimes, we're left with bad ideas because all the good ones aren't available.

While you asked about not creating all the records, your best choice, outside of ISV intervention, would be to create all the records. It's a pretty lousy choice, but thankfully, you generally only have to do this once. You might even decide to put all the data in a static resource and use Test.loadData.

If you really can't afford the time, then use SeeAllData=true. This lets you use live data, so use your best discretion here. Dependencies on live data can break your deployments at a critical moment, so make sure those records are protected or tucked away somewhere so some user doesn't accidentally modify/delete them. For example, assign them to a system administrator to reduce the odds that they'll get changed/deleted.

Also, depending on your code, you might be able to fake some of the records. This gets pretty interesting if you're not careful, but I've managed to deserialize complicated objects with relationships, then inject them at critical points in the code. I'll see if I can find an example in my old source code, but you should know that JSON.deserialize can definitely work around situations where you don't need to DML against or query the records in question (i.e. the code is designed simply to read or write field values).

Answer 3

If you are (very) lucky the managed package provider will have implemented a globally visible custom setting to turn off those constraints that you can set programmatically in your test. Through bitter experience, we now do this for our managed packages. (This switch is also valuable when doing some bulk data loads.)

But more commonly, you will have to fix each error in turn by modifying the data you create. Remember that if you add your own local validation you will have to code for that too. So your test setup ends up pathologically coupled to logic that you don't want it to be coupled to... A sad fact of life on the platform. If you are writing several classes yourself and therefore tests for those class, creating your own test data builder class so the coupling is located in one place makes sense.