It’s finally generally available with the Spring ’17 release; the Apex stub API! This is really going to make your unit tests easier to write and enable you to write more meaningful tests.
In this post I’ll cover why this is such a big deal and how you can incorporate it into your unit tests going forward.
Queueable callouts in Apex just became even better in the latest release of Salesforce as you can now make webservice callouts in chained queueable callouts!
One of the coolest updates within the Spring ’17 release notes I found was the ability to now natively use the Lightning Design System directly inside Visualforce without needing to upload or reference a static resource.
Why is this cool? Simple. You don’t contribute to the overall limit of how much space your static resources take up and you benefit from always having the latest version of the Lightning Design System incorporated into your pages.
In this release Salesforce has added the new apex:slds tag.
As developers we are frequently capturing data from form input, validating and displaying errors back to the user when validation criteria are not met. Other times we have to create strings such as URL’s with dynamic parameter values or even queries with dynamic where clauses.
In this blog post I want to demonstrate a much better approach on how to create dynamic error messages or even other types of strings using the under used String.format method.
Make unit testing even easier with a new pilot from Salesforce, a new mocking API.
This is going to be really interesting how it affects existing projects such as FFLIB Apex Commons and ApexMocks which offer similar functionality.
This is the next in the series covering FFLIB and the enterprise design patterns. Previously I covered the unit of work pattern (UOW).
As mentioned in my introduction to FFLIB, the service layer is where we will place all of our business logic in our application. Think of the service layer of where you orchestrate all of your business logic.
It aims to solve one of the more common issues in larger applications, whereby logic becomes scattered or even worse, duplicated. By keeping our business logic defined in central place we encourage reuse and reduce logic from being scattered, increasing maintainability.
This is the next in the series of FFLIB posts in which I’m trying to cover in the upcoming months. In my last post I covered the selector layer and how it can really help centralise your queries in your application. The next logical layer in FFLIB to cover now is the unit of work pattern
The unit of work pattern (UOW) is aimed at solving some of the common design issues in Salesforce applications when dealing database operations and bringing additional functionality to make your life as a developer much easier.
You can now find the Winter ’17 release notes online!
https://releasenotes.docs.salesforce.com/en-us/winter17/release-notes/salesforce_release_notes.htm
This is the next post in a series of posts covering how to use FFLIB in your project. In this post we will be covering the selector layer, the part of the application which handles all of your queries. Last time we covered a basic introduction to the domain layer.
Quirky Apex 