Trailhead is an interactive learning path through the basic building blocks of the Salesforce1 Platform. Test your knowledge of the platform while earning points and badges to celebrate your achievements. All of this is broken down into different modules, making it easy for every developer to learn Salesforce in a few hour chunks. This series will follow a different module each post, giving a comprehensive analysis of the module. The focus of this post will be on expanding what is taught in the module into greater depth and taking your experience beyond Trailhead and into more actual Salesforce work.
This is a fantastic start to explaining unit tests. I think the fifteen minute estimate is valid, although the test scenario using
Date classes can be tricky for someone first learning unit tests. That may push it out past fifteen minutes. I’d suggest reading up on the Date class more and experimenting with it. While that wasn’t the focus on this specific piece, it can be trickier than other primitive data types, so it is good to get some practice.
Outside of that, there were a few oddities that I noticed. One, the challenge asks for you to create
TestVerifyDate yet the example always ended their classes with Test rather than prepending it. Either way is fine, but it is important to be consistent when writing your test classes. Find a good paradigm that works for you and stick with it. I’d also suggest consistently using camelCase. Some of the code here did not always use it. You can choose your own formatting, but Apex typically uses camelCase so it wouldn’t be a bad idea to keep that in mind. Consistency is key to great development.
Triggers are an interesting aspect of Salesforce that can cause headaches if done improperly. This example is pretty straight forward, but I would highly consider following Salesforce’s own posted Trigger Best Practices. Specifically, the use of logic-less triggers, one trigger per object, etc. By using a framework like this, it will be much easier to breakdown where your logic exists in real world situations as well as properly test the implementations outside of a specific trigger.
It was a fantastic idea to call out the usage of a Test Utilities class for creating your data. That is a common mistake I see most new developers make (by not having one). I also thought the mention of branch coverage was a good idea. I felt this module was really good (despite some of the naming issues I mentioned above). I’d consider taking this to the next level by utilizing the new
@testSetup annotation to encapsulate your data creation in a single location. I’d also consider more complex Test Utilities classes.
Overall, I’d say this is a fantastic module. Some minor chances to expand, but for the most part they include some great concepts for developers new to unit testing.
I highly recommend Trailhead for everyone. Even if I called out some different things that could be expanded on, it doesn’t change my opinion that Trailhead is a fantastic tool for learning the development practices on the Force.com platform.
For more information related to Trailhead, please read the Trailhead FAQ.