Hello all you trailblazers! Every day it seems as if there is a shiny new Salesforce Badge or even better a super shiny new Superbadge to add to your collection. Having just completed a number of Superbadges as part of the new Platform Developer II Certification, I am here to tell you sometimes you have to jump through hoops when your code is working according to the specifications but you cannot pass one of the challenges. It can be enormously frustrating to get hung up on the small details.
In this article I share a few tips with you – not giving away the answers or the code mind you, but rather providing a little nudge in the right direction to ensure you are not getting tripped up by something as simple as a variable name.
A little background..
The Platform Developer II Certification format has been completely revamped. Now rather than doing a programming assignment, there are a series of Trailhead Superbadges to complete. Easy enough right? But wait… Each Superbadge has a number of pre-requisite required Badges. And each badge has a number of trailhead challenges to complete… So it is a labor-intensive exercise. Don’t be fooled into thinking it is easier than the first approach. I have done both – they both have their challenges and I have learned an enormous amount with both approaches which is the goal after all!
Name your variables and fields EXACTLY as the Superbadge states in the requirement.
If you have a Lightning component that you want to invoke from another Lightning component’s JS method, and the component is named Booking, you should call your variable in the JS method Booking.
When writing JS controller methods for Lightning components, use the full names for the method parameters. This is even stated in the pre-cursor for the Lightning Superbadge: When coding controller functions, use the naming convention function foo(component, event, helper) as opposed to function foo(cmp,evt,hlp).
This one wins the cake for the most puzzling issue and honestly, I think Salesforce needs to work out some of the kinks for these newer Superbadges and perhaps they have already by now. Anyhow… I got dinged for having too many test records. The program that was verifying the results expected a certain number of records for a particular custom object based on the number of records that had been created in previous trailhead challenges. The additional records I had created for testing meant that the challenge failed even though the implementation was correct.
For instance, if you are supposed to build out a Queueable class, use implements System.Queueable and NOT implements Queueable.
Many of the Badges and Superbadges have you start by installing an unmanaged package with skeleton code.
The method signature(s) in the code should not be altered, for instance, if there is a Trigger with a corresponding Apex class to handle the Trigger logic, leave the Apex method signature exactly as it was created. Often times the skeleton Apex handler provided only takes a single list/map of records (the new records) as an argument which does not work well for Update Trigger handlers as you usually require access to both the new and old lists/maps. And the starter code is not consistent – sometimes the Trigger handler code did specify for the new and old lists/maps and other times it didn’t.
The starter code may have constructors or methods that are used for package installation and unit tests. If you need a different constructor or signature with the same method name, then override it rather than changing the signature and related tests.
If the instructions tell you to use a method to provide certain behavior, even if the method will only have a single line of code and does not provide any additional value (reusability, encapsulation, etc), use the method and name it according to the instructions. The robot grading your submission will be looking for this method name and invocation.
Finally – the biggest tip of all is the time-honored KISS Principle. Keep It Simple Silly 🙂 The series of Badges and Superbadges that culminated in the certification all test your knowledge on different subject areas and context within the Salesforce platform. There are Badges to gauge your knowledge of unit tests, others to gauge your knowledge of callouts, others to gauge your knowledge of governors limit, Lightning knowledge, Visualforce, batch and scheduled jobs, etc. Other than following best practices, do not go crazy and try to have one implementation or test case serve all of the different purposes. One ring does not serve them all…
And if you need any help, our developers are on the trail to help you become superbadged with Salesforce. Happy trailblazing!
Sign up for weekly OpFocus blog updates!