Developer Packaging Guideline – Managed Packages help you avoid installation failures

I recently made a big learning about the difference between managed and unlocked/unmanaged packages: when a user tries to install an unlocked package, all of the tests are run, but when a user tries to install a managed package, the tests are not run.

This prevents managed package tests from interfering with validation rules on the target org.

What we were seeing with typical unmanaged packages on UnofficialSF: the developer would write tests but customers trying to install the package to their production org reported installation failures because the tests create test records like Accounts or Contacts, and these record creates were failing for miscellaneous reasons (missing a custom field that is required on that particular user’s org, for example).

I asked the product manager of Apex, Chris Peterson, who wrote:

 I would absolutely recommend managed to make it so that your flow-centric admins don’t end up owning Apex tests they can’t maintain). If they want the source they can grab it off github, but managed packages should be your “easy turn-key” option.

For managed packages: the tests run on pkg creation, and only run on install when the test is explicitly annotated requesting this. Managed tests are NOT run on metadata deployments to the org, unless specifically requested.

For (1st gen) unmanaged packages: this is a real problem, and one of many reasons why I generally discourage the use of 1st generation unmanaged packages entirely.

For 2nd gen unlocked packages: I have less experience, and if this is what you’re asking about let me know and I’m happy to go do my homework, since I should probably know this anyways.

At the end of the day, it’s not possible to make a test that does any DML that will succeed anywhere, at least not practically. Using the right delivery mechanism to ensure test ownership is assigned correctly (i.e. to you, the provider for managed, instead of to your subscriber for unmanaged) is by far the superior option to trying to make a “works anywhere” test.

As a result, we’ll be switching to managed packages wherever possible on UnofficialSF.

Subscribe
Notify of
guest
1 Comment
Inline Feedbacks
View all comments
Matt Comer

Yes, Unlocked Packages are really perfect for “enterprise development” on the platform – that is, they’re fantastic for developers and admins working within an organization on projects which live within an org they control. Unlocked Packages bring the deployment simplicity of Managed Packages into the enterprise development space but without the overhead – namespaces (unless you want them), packaging orgs, review, etc. That being said – they were never really meant for distributing software OUTSIDE an org IMHO.