Test an AppExchange App
After completing this unit, you’ll be able to:
- List test coverage requirements when using Apex.
- Describe specific tests to perform when creating an AppExchange app.
- List the types of security vulnerabilities your tests must address to pass the security review.
Just to be clear, we know that you know the importance of testing. In this unit, we touch on some Salesforce-specific criteria around testing and, more importantly for you, some AppExchange requirements around testing.
Apex has a built-in testing framework, an essential tool for any developer. Salesforce also requires using the framework to ensure that no code is taking more than its share of resources.
A basic requirement is that your tests must cover at least 75% of all Apex code in your package. However, we recommend that you get as close as possible to 100% coverage. You can learn about other requirements in the Apex Testing Trailhead module or in the Understanding Testing in Apex section of the Apex Developer Guide. Whenever you upload a package, all the tests are run. If even one test fails, your upload fails.
There are some poor coding practices that you can get away with in a single org but they cause an AppExchange app to fail. Some of the most common “gotchas” are the result of hard-coded values. In particular, never hard code:
- Record IDs, which are unique across orgs
- References to values that a customer can change, such as picklist values or record type names
Also consider that your customers could be using platform encryption. Document the standard fields of standard objects that you are relying on in your app. If you want to support customers who use platform encryption, test that your app doesn’t break if those fields are encrypted. You can then label your app as supporting encrypted fields on the AppExchange. Check out the Platform Encryption section of our help and training docs for more information.
We recommend that you employ the standard practice of merging all code daily to make sure that modifications and additions don’t break existing code.
We suggest you set up a source control system (1) where your developers can check in the metadata files they’ve created or modified. Then push the metadata from the source control system into a common partner developer org (2) daily and run automated tests against the app.
As when developing any piece of software, make sure that your tests verify that:
- Your Apex code works correctly, passes all tests, and meets test requirements.
- Your custom UI displays and reacts as you expect.
- Your business logic meets requirements and doesn’t do anything extra.
Because you distribute your app to customers in a package, release testing for AppExchange partners includes testing the app in its packaged state. You want to make sure that the package installs correctly and that all functionality works as expected after the installation.
A few components, such as approval processes, can’t be packaged. Document any required configuration or setup, and include reviewing those instructions as part of your testing.
As you release subsequent versions of the package, testing includes ensuring that existing customers can install the new version of your app. Verify that the new version works in both a fresh org and an org that has previous versions installed.
For initial package testing, start with a Managed Beta - Package. While your app is in a beta package, you can make any type of change you want.
The flow for using the beta package looks something like this.
- Push changes from your source control system into your beta packaging org.
- Create a Managed Beta - Package containing your app.
- Upload the package.
- In the test org:
- Install the package and test.
- If issues are found:
- Uninstall the package in the test org.
- Update your app in the beta packaging org, and edit your package contents if necessary
- Return to step 2.
- If no issues occur and development is complete, it’s time to move to a Managed - Released package.
Notice that you uninstall the beta package and install a new beta package in your test org during the build and test cycle. Beta packages aren’t upgradeable, so you can’t install one version of a beta package over another. For more information, see Uninstalling a Package and Installing a Package.
The checklist includes items to verify that:
- Your code honors the field-level and object security specified by an org’s Salesforce admin. Pay particular attention to this topic because it causes many apps to be flagged during security review.
- You have implemented encryption when transmitting data on and off the platform and storing sensitive information, such as login credentials and customer data, off the platform.
The security review includes running several tests against your app. You can run some tests before submitting the app. Incorporate them into your testing cycle.
When you upload your package, you can set package and object requirements that customers’ orgs must meet to install your app successfully. Don’t worry if you don’t know what to select here. It comes with experience, and the stakes are low—usually the defaults are fine.
Some values are auto-enabled based on what is in your package. Verify that this list has the correct values for your app so that no errors occur when the package is installed.
For example, Chatter-related components or communities could be auto-selected. If customers’ orgs have these features disabled, attempting to install your package fails.
When you think your app is bug free in its packaged state, it’s time to create a Managed - Released package in your beta packaging org. How do you create a released package? It’s just an option when you upload your package.
Then send the package through one more round of tests.
When all is good, it’s time to use the golden package org.
- Move your app to your golden package org using a migration tool.
- Set up your customer-facing namespace.
- Package up your components.
- Create your Managed - Released package.
- And then, yes, do one more round of tests.
When all that is done, it’s time to send off your app for security review. After your app has passed the security review, it’s time to sell.
Most testing on the platform follows standard best practices. Tests determine that you’ve:
- Met functional requirements
- Written tests to verify your code
- Addressed security vulnerabilities
When testing a package, also verify:
- External code correctly references namespaces
- Installation instructions
- Package and object requirements
You’ve done it! You now know all the basics for using AppExchange partner tools to develop your app. Go forth. Learn more. Write that amazing app.