Salesforce offers the ability to develop solutions with clicks or code. This offers flexible ways to achieve requirements and often means the same requirement can be achieved in many ways.
As a Salesforce Administrator, it’s unlikely you’ll develop any code-based solutions in Apex yourself. However, changes you make can still break Apex Tests developed by others! In this article, we will explore some of the ways you could upset existing Apex Tests.
What’s an Apex Test?
Apex Tests are like a health check for your Apex code. They are designed to enforce sufficient code coverage (75%) and ensure the code operates as it should.
Apex Tests are written at a point in time so as your org evolves your health checks may need to be adjusted to keep up with the latest changes. If an Apex Test no longer runs successfully this could be for a whole host of reasons including missing records or permission changes.
10 Ways You Could Break Apex Tests
Salesforce Admins and Developers know that maintaining a clean, functional, and efficient Salesforce org requires constant vigilance and careful planning.
However, even the most minor changes to your org can create ripple effects, particularly when it comes to Apex Tests. This top ten list highlights some common scenarios – from introducing validation rules to changing permissions – that can break Apex Tests and cause headaches for your team.
1. Validation Rules
A Validation Rule is a clicks-not-code way to ensure data is valid before it’s accepted by the system. Define a rule name, condition, message, description, error location, and mark active to build logic that only accepts valid data.
Let’s say you have an Apex Test that attempts to insert an Account with the name ‘Test’. If you then introduce a validation rule that rejects any Account with the name of ‘Test’, your Apex Test would fail when its next run.
If you are trying to debug an issue that sounds like this, then look for FIELD_CUSTOM_VALIDATION_EXCEPTION in your Apex Test Results.
2. Duplicate Rules
Suppose you’ve introduced duplicate rules in the system to prevent a pile-up of duplicate contacts in the system.
If you then run an Apex test that tries to insert a duplicate contact, it would fail – an error message like DUPLICATES_DETECTED, Use one of these records?: [] would then appear.
It may be great for Marketing that you no longer have duplicate Contacts, but this could come with the cost of refactoring any Apex Tests that no longer work as a result.
3. Other Automations (Flow, Apex, Approval Process, etc.)
Let’s say you’ve introduced a flow that displays a custom error when you try to create an Opportunity without an Opportunity Contact Role of Decision Maker. This is great for data integrity, but not so great for an Apex Test that inserts an Opportunity without Opportunity Contact Roles. This Apex Test would fail with FIELD_CUSTOM_VALIDATION_EXCEPTION.
Remember that Salesforce Flow is not the only type of automation you can introduce and so other types of Automation (eg. Apex class, approval process) could equally upset an Apex test.
4. Required Field
When you create a field in Salesforce you can set this as required at either the field level, on the page layout, or on the Lightning record page if using Dynamic Forms.
If you have a historic Apex test that inserts a Case and you introduce business unit as a required field (on the field level) that isn’t set in the Apex test, then the test will fail. Within the results, you’ll see something like REQUIRED_FIELD_MISSING to indicate the error.
5. Unique Field
Sometimes you may need to mark a field as unique. For example, each Account has to have a unique Customer Number. If you insert an Account with the Customer Number ABC123 and then try to insert another with the same reference, you’ll get an error message.
If this happens in an Apex Test, you’ll bump into an error too which may look something like DUPLICATE_VALUE. You may have to dive into this further to understand which field this is coming from as the standard error doesn’t tell you this information (from my own testing).
6. Restricted Picklist
Suppose you are approached by the sales director who wants to adjust the picklist on the Account Object for region. Your organization has stopped trading in EMEA (Europe, Middle East, and Africa), so this picklist value needs to be removed from this picklist, which happens to be restricted.
Should this value be removed and an Apex test later try to insert an Account with the same value, then this would be blocked – with an error message that looks a bit like INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST. This would usually be followed by the invalid value and field API name for easier troubleshooting.
7. Record Type
As a Salesforce Admin you may want to make a Record Type inactive. For example, if you retire a business process and no longer need the related Record Type. Once you’ve made the record type inactive in your sandboxes and deployed it to production, you may think you’re all set.
However, if an Apex Class fetches a Record Type which is now inactive when you run Apex Tests, you’ll get an error message similar to INVALID_CROSS_REFERENCE_KEY.
8. Lookup Filter
Let’s say you have a Custom Object. This has been around for a while, but people keep on relating invalid Accounts. So you decide to add a lookup filter to only allow an Account where Active = Yes.
When you next run Apex tests, these could fail if tests try to create a record with an Account that isn’t active. This would show up as FIELD_FILTER_VALIDATION_EXCEPTION.
Ensure error messages are clear to facilitate better debugging.
9. Permission Changes
In Apex tests, users can be created with specific permission sets, permission set groups, and profiles. If you have an Apex test that currently relies on a specific setup and you happen to change the same setup, these tests could fail.
For example, if you insert a user with the operations permission set that no longer can edit Contacts and the test tries to do that, it could fail. These types of errors can show up in various ways depending on how the Apex is written.
10. Installed Packages
The AppExchange is a great one-stop shop to browse apps you can easily install to extend your Salesforce functionality.
Some of these packages include Apex code within them to perform complex logic or call out to external systems. Did you know that your configuration can cause these Apex tests to fail as well?
If this is the case and the code is managed, then you may become stuck trying to fix the issue. Managed code is not readable, and as such you can’t change the logic to make it valid.
How to Proactively Avoid Breaking Apex Tests
By being a “responsible citizen”, an admin can ensure that any changes they make don’t upset Apex tests elsewhere.
This starts with active communication with developers during the development lifecycle from requirements gathering, backlog refinement, and implementation through to testing, etc. By engaging with developers who have an understanding of what may be impacted, potential issues can be caught early.
Towards the end of each sprint, run Apex tests to ensure that things haven’t been impacted by changes. If you were to run these at the start, you could compare any differences. By catching issues towards the end of the sprint you’d be able to make quick fixes or plan for more complex fixes in the next sprint.
If you do not run Apex tests regularly you may only discover issues when you need to adjust the existing code, which in turn could take longer than expected.
Summary
As admins, let’s be proactive and catch issues early so that someone doesn’t have to clean up our mess in the future! Let’s be more forward-thinking when we develop new functionality so that it doesn’t interfere with Apex tests.
Resources
- Apex Testing (Trailhead)
- Testing Apex (Salesforce Developers)
