Red Argyle Logo

The Salesforce Blog with Tailored Goodness

Salesforce Spring ‘16 Release Notes: Get Ready for Changes to Apex Testing

The Salesforce Spring ‘16 release is imminent, and with it comes a long list of changes. As a developer, the changes that most excite me are generally those that are covered in the Development and Deployment categories of the Salesforce release notes. I’ve gone through all the changes in those sections and while there were a lot of notable improvements, the 3 that most stood out to me are all related to Apex Testing.


Test Suits for Apex Test Classes

With the Spring ‘16 release, Salesforce has now added the option to group unit test classes into test suites. A test suite can be used in a number of different ways, but there is one immediate case that I will be using them for–to bundle sets of related and similar unit tests into a single suite. Oftentimes, when developing a new feature, I end up with several different test classes that I want to run together when testing the feature. The new class-grouping option will simplify things in that I won’t be required to remember which tests to select and can instead cover my bases by running a single test suite.

Test suites will be added to the Developer Console, and the Tooling API has been updated with API calls to create and run test suites. However, my daily development environment relies on
MavensMate, so I’m hoping that their team is close behind in incorporating test suites into their app.


Stop a Failing Test Run Early

It’s not uncommon for a single change to percolate through a Salesforce org and break a large number of unit tests. I see this most often with validation rules, which can be easily added and can just as easily cause unit tests to fail. When working in an org that has had a number of changes that resulted in failing unit tests, it can be a tedious affair to figure out exactly which changes have affected the unit tests. With Spring ‘16, Salesforce will now allow you to set a test failure threshold which will stop the execution of a set of unit tests after that number of failures is reached. This means no more waiting for the entire list of unit tests in a test run to finish and can potentially speed up the bug hunting process by quite a bit. The test failure threshold is being added to both the Developer Console and the Tooling API. As is the case with test suites, I’m looking forward to this being added to MavensMate.


Set the CreatedDate Field in Apex Tests

I’ve been waiting a while for this change and have always wondered why it wasn’t already included. When a record is created in Salesforce, the CreatedDate field is stamped automatically and can never be changed, even inside of unit tests. The fact that the value couldn’t be changed in a unit test made it difficult, or even impossible, to fully test code that relies on the CreatedDate of a record for its functionality. A typical example of this would be a scheduled batch class that runs every night and updates records that are older than a certain time period. Currently, when records are created in a unit test, their CreatedDate field is set to today, so it is not possible to then test a class that only updates old records. It was announced in the Salesforce Spring ‘16 release notes that the Apex Test class will now include a setCreatedDate method which can be used in unit tests to solve this problem. This seemingly minor addition will go a long way in improving test coverage for Apex code that relies on the CreatedDate field.


What do you think of the Apex Testing changes announced in the new Salesforce Spring ‘16 release? Did I miss something in my highlights that you think is worth mentioning? Let us know in the comments below!