The Salesforce Spring ’16 release is right around the corner and there are some noteworthy features for developers. In this post I call out a few of the Spring ’16 developer tidbits and explain their significance.
Tidbit 1 – Visualforce for Lightning
Lightning Components for Visualforce were made generally available in Winter ’16 and now Visualforce for the Lightning Experience is beta in the Spring ’16 release.
When you edit a Lightning Experience Record Home Page, you’ll notice a Visualforce component in the list of Standard Components. This allows you to drag on to the record home page any Visualforce pages that contain standard controller for the object’ whose record home page your editing. What’s cool about this feature is that if you have some sort of functionality in a VF section of a page layout in classic you can easily port it into the Lightning Experience. You may wish to style it differently, though, depending on the context, which leads me to the next cool tidbit…
Tidbit 2 – User’s Theme
- Theme1 – ObsoleteSalesforcetheme
- Theme2 – Salesforce Classic 2005 user interface theme
- Theme3 – Salesforce Classic 2010 user interface theme
- Theme4d – Modern “Lightning Experience” Salesforce theme
- Theme4t – Salesforce1 mobile Salesforce theme
- PortalDefault – Salesforce Customer Portal theme
- Webstore – Salesforce App Exchange theme
Tidbit 3 – Unit Test Suites
Unit Test Suites are something that give us the ability to better organize our tests. They are currently available to be used in the Developer Console and also the REST, SOAP, and Tooling APIs so, hopefully, if they aren’t already, they’ll soon show up in other tools.
Unit Test Suites give us the ability to organize our tests into meaningful higher level groups. For example, there might be a suite for running tests related to Community code in your org, a suite for testing a custom coded pricing app, or others. You might have a smoke test suite that you run on sandboxes after refresh. If organized correctly, it also gives a self-documenting guide to functionality for new devs. If someone wants to learn about the code associated with communities, they can go to the Community Test Suite and run and look at the well-named methods and various classes under test in the suite.
Tidbit 4 – Set Created Date in Unit Tests
Yes. This is here! There is a very highly voted question on the Salesforce Stack Exchange about how to set the created date in unit tests. There are answers that use JSON serialization and Test.loadData and now there is one that uses Test.setCreatedDate(Id sObjectId, Datetime createdDateTime). Note that it can’t be used in SeeAllData=true tests.
Sometimes you might have code that executes conditionally or otherwise based on whether or not a record was created within a certain time period (e.g., all records created more than a week ago that have not been modified since). In the past that type of code was harder to test. With this new method it is much easier.
Tidbit 5 – Sandbox Post Copy Script
You can now specify an Apex class to be run after a sandbox has been copied. It must be global and implement the SandboxPostCopy interface which has a single runApexClass(SandboxContext) method. I haven’t worked with Sandboxes in a couple of years, so I have yet to play around with this to see its full capabilities, but there are a ton of different use cases — environment specific configuration changes (e.g., call out end point urls and credentials), data alteration (e.g., email addresses), and possibly quick data creation or data validation. I love this feature, because lists of manual post sandbox refresh steps can hopefully be whittled down to near nothing and replaced with intelligent automation.
Tidbit 6 – New Apex Site Class Methods
There were a few new methods added to the Apex Site Class. The two that I thought were the most interesting are Site.isValidUsername(String username) and Site.validatePassword(sObject User, String password, String confirmPassword). The isValidUsername method is useful because now our custom pages for user management can easily detect whether the newly entered user name is valid without hard coding some validation logic against an entered string or without waiting for a DML operation to fail. The validatePassword is really nice, since different password policies may exist depending upon what is configured. Like with the isValidUsername, we no longer have to rely on hard coding or waiting for the Site.changePassword method to not work.
More Spring ’16
I’ve shared 6 interesting developer features in Spring ’16 and why I find them particularly interesting. There are many more interesting features for developers. I encourage you to take a look at all of the Spring ’16 resources and release notes, get a pre-release org, and check out the Maintenance Calendar at trust to get a full picture of the Spring ’16 maintenance release dates. If you want to hear me go into more depth on some of these feature and a few other ones, check out my Developer Group presentation.