The straightforward answer is no. When you install a managed package from the AppExchange or via a link into your Salesforce org, the Apex test classes included in that package do not run by default.
This often surprises people because Salesforce is famous for its strict “75% code coverage” rule. However, the logic behind skipping these tests during installation is designed to protect you, the subscriber, from unnecessary headaches.
In this post, we will explore why this happens, the rare exceptions where they do run, and how this impacts your overall org health.
Why Salesforce Skips Tests During Installation
Imagine you are installing a complex Accounting package. That package might have 500 test classes. If Salesforce forced those 500 tests to run every time someone installed the app, two major problems would occur:
1. The “Unique Org” Conflict
Every Salesforce environment is customized. You have your own Validation Rules, required fields, and Workflow Rules. A managed package developer writes their tests to pass in a “clean” environment. If those tests run in your org, they might fail because your custom Validation Rule blocks the test data the package is trying to create. If the tests fail, the installation fails—meaning you could never use the app simply because of a local setting.
2. Deployment Speed
Running hundreds of tests can take hours. To make the AppExchange experience seamless, Salesforce relies on the “Managed – Released” status. When a developer uploads a package version, Salesforce runs all the tests in the developer’s packaging org. Once it passes there, Salesforce “certs” the package as stable, so it doesn’t need to prove itself again in your org.
The Rare Exceptions: When DO Managed Tests Run?
While the default is “No,” there are three specific scenarios where managed package code might be tested in your environment.
1. The @isTest(OnInstall=true) Annotation
Developers have a special tool called the OnInstall parameter. If a developer labels a test class with @isTest(OnInstall=true), that specific test will run during the installation process.
- Why use it? Developers use this for “Smoke Testing.” It checks if the basic environment is compatible with the package.
- What happens if it fails? If an OnInstall test fails, the entire package installation will fail and roll back.
2. Choosing “Run All Tests” During a Deployment
When you are deploying your own custom code (unmanaged code) from a Sandbox to Production using Change Sets or an Ant/SFDX tool, you are asked to choose a “Test Level.”
- Run Local Tests: This is the default. It runs only the code you wrote. Managed package tests are ignored.
- Run All Tests: If you select this, every single test in your org runs, including those inside installed managed packages. This can significantly increase your deployment time and is generally avoided unless necessary.
3. Manual Execution
As an Admin, you can go to Setup > Apex Test Execution at any time. You can click “Select Tests” and choose the namespace of any managed package. This allows you to run their tests whenever you want to ensure that your recent org changes haven’t broken the package’s internal logic.
Managed Package Tests vs. The 75% Code Coverage Rule
A common concern for Admins is: “If I install a package with 0% coverage in my org, will it bring down my overall Org Code Coverage?”
The answer is a resounding NO.
Salesforce calculates code coverage using two different buckets:
- Local Code: This is the code you or your consultants wrote. This must have 75% coverage to deploy to Production.
- Managed Code: This code lives in its own namespace. Its coverage is tracked separately and does not count toward your local coverage requirements.
If you have 80% coverage on your local code and you install a massive managed package, your local coverage remains at 80%. You don’t have to worry about a “bad” package ruining your ability to deploy your own code.
Troubleshooting Installation Failures
If managed tests don’t run, why do installations sometimes fail? If you see an error during installation, it is usually one of the following:
- Component Name Conflicts: You already have a field or object with the same name as something in the package.
- Missing Features: The package requires “Person Accounts” or “Multi-Currency,” but you haven’t enabled them.
- Post-Install Script Failures: Many packages run a “Post-Install Script” to set up data or settings. If this script hits a governor limit or a validation rule error, the installation will fail. This is often confused with a test class failure.
- Package Dependencies: The package might require another package to be installed first.
Best Practices for Salesforce Admins
To ensure a smooth experience with managed packages, keep these three tips in mind:
1. Always Install in a Sandbox First
Since you can’t see the code inside a managed package, you don’t know how its triggers will interact with yours. Always install in a Sandbox and run your own local tests to see if the new package broke your existing processes.
2. Use “Run Local Tests” for Deployments
When moving your code to Production, avoid selecting “Run All Tests” unless specifically required by your DevOps policy. Stick to “Run Local Tests” to keep your deployment windows short and avoid failing on code you didn’t write.
3. Check the “Apex Test Execution” History
If you suspect a managed package is acting up, go to the Apex Test Execution page and manually run the tests for that package’s namespace. It’s a great way to provide the vendor with logs if you need to open a support ticket.
Conclusion
To wrap it up: Managed package tests do not run during installation. They are pre-validated by Salesforce to ensure they meet quality standards before they ever reach the AppExchange. This system is designed to make your life easier by preventing local org customizations from blocking your ability to use third-party tools.
Understanding this distinction allows you to focus your energy where it matters most: maintaining high-quality coverage for your own local customizations.