The Winter 13 (API 26) release has no substantial impact on the accuracy and recommendations in the book.
Check back here periodically for updates.
Details on individual changes:
Non-Prmitive Types in Map Keys and Sets
It looks like the issues raised chatper 5, Fun with Collections, are exactly as I described. Yes, you can use objects as types in map keys and sets, but except for unusual cases you should avoid doing so – as any field change to the object will effectively change the key (field values determine uniqueness). We’ll see how this plays out once I have my hands on released code, but so far I don’t think this changes anything in that chapter.
Support for Testing Callouts
Very nice. Has no impact on the book, as I didn’t delve into this issue. I do use a callout simulation in the book, but it’s in an illustration of asynchronous design patterns rather than testing of a specific callout. I might look at using this feature in the example in the next edition, but I’m not sure that would work given that I don’t implement an actual callout that this feature could work with. As it stands, this is a great feature, but has no real impact on the chapter.
Loading Test Data from Static Resources
At first glance you’d think this is a huge win, but there are still some unknowns and compromises involved.
One question is – how many objects can you insert in this manner? If this method bypasses DML limits, it could be extremely valuable for testing on large datasets – something not possible today. I bet it doesn’t though.
Data in a static resource counts against organization data limits – test code does not – so there is some cost to this approach.
It’s a shame the function inserts the objects (as implied by the release notes) – it would be better if it just loaded the objects into memory so you could then modify fields before completing the insert. This would provide extra flexibility. Inserting and updating the fields may not be a good solution depending on the application.
This doesn’t really resolve the problem of deploying managed packages – unless you’re going to provide customized sample data resources to each org before you deploy. The static resource based approach described in the book is more flexible, and you can place all of your information in one smaller static resource than multiple larger static resources.
One option might be to do a test for the presence of a resource before running a test – use the resource if found, otherwise use the standard test code.
If you do use this feature– the approach described in the book for centralizing test object initialization will prove helpful.
One place where I’m thinking this feature can be particularly valuable is in regression testing and QA. In particular, it could be very handy for allowing QA personnel to validate a system without requiring code changes. I’ll be exploring these scenarios further for the next edition of the book. This will likely be an area that I’ll add new content to the book – as compared to changing existing recommendations.
SOQL Polymorphism
As far as I can tell, this doesn’t impact any of the examples in the book.
Creating sObjects with Default Values Using the newSObject Method
I still plan to experiment with this one. It may be the preferred way to create all new test objects going forward. If so, it will impact the book but will largely be a search and replace on the text. Note that this function does it right – it initializes the object but does not insert it. Beautiful. This is another demonstration of why a centralized test object creation architecture is so important – even on a large application you may need to make only a handful of code changes to use this great new feature.
The following new features are very nice, but at this time I don’t see that they have any impact on the book
New ID.getSObjectType method – can eliminate a Describe call in some scenarios.
New getVariableValue method – The book doesn’t cover Flows.
New String Methods – Fantastic library will help reduce script line use in many cases. But has no real impact on mid to high level design and architecture.
Global Interface Method Implementations No Longer Need to be Global – Nice, but again, no major design impact.
New Type.toString Method – Would be a whole lot more valuable if Apex had a Select Case statement. Still can save some script lines in certain scenarios.
String.valueOf and System.debug Use toString for Argument String Conversion – This is ultimately a really nice change. Still not sure what impact it has on practical debugging.
JSON Support for Additional Built-In Types – Great if you’re using any of those types. The book doesn’t.
