Archive for the ‘Testing’ Category
For a time I’d wondered what the difference between the System.Assert and System.AssertEquals methods might be (System.AssertNotEquals to a lesser degree). To be honest this tip isn’t going to help much with World Peace or Curing Internetlessness, but it’s certainly gonna save you some time.
Looking at the documentation there are some obvious differences.
- System.Assert accepts two parameters, one (mandatory) which is the condition to test for and the other a message (optional) to display should that condition be false.
- System.AssertEquals and System.AssertNotEquals both accepts three parameters; the first two (mandatory) are the variables that will be tested for in/equality and the third (optional) is the message to display if the assert results in false.
Pretty standard stuff, and can all be learnt simply by Reading The Manual.
Now testing best practices state that you should assert some condition but also output a “console” message that shows the values of each of the operands. This certainly helps you debug unit tests when asserts are failing, but man I hate typing extra code just to check out some variable values! So the time saving trick that isn’t obvious is that when omitting the optional third parameter for System.AssertEquals and System.AssertNotEquals the compiler automagically outputs the values of the operands to the console log. That’s right, instead of typing:
System.assert(var1 == var2, "The value of var1 is: " +var1 + " and the value of... oh hell I don't care I mean it's just a variable");
You could type:
If the second assertion fails the console will output the values of var1 and var2 with the labels “expected” and “actual”. Knowing this now I can see no exceptional reason to use System.assert any longer (sorry little guy).
As I said this trick’s not gonna start any Mexican Waves but it should help delay the onset of RSI.
(thanks to l-dawg for opening my eyes)
Recently, Jeff Douglas and I saw the potential for a beginner’s book – aimed at business owners, analysts and developers, that comprehensively documents Salesforce and Force.com. There is a tonne of documentation out there and we thought “Wouldn’t it be nice to have a handbook that lightly summarised the most important areas of the platforms as well as offering some best practise advice”. We mulled it over for a time, and today we’d like to announce that we’re currently writing:
The Salesforce Handbook
A newcomer’s guide to building applications on Salesforce.com and the Force.com Platform.
Hand-in-hand with the book we’ll be publishing content from the book on a WordPress site. Here you can expect to find excerpts from the book, but also content that supplements the book e.g. areas that’ll serve as best-practice hubs with links to official documentation, blog posts that rock the party, and even superb discussion forum threads.
We’d love to get your feedback on the book as it progresses, but for now you can checkout the announcement and let us know what you think of the idea.
Unit testing *sigh*. Oh how they vex me. If they weren’t so important (and required) I’d just skip the lot, but they are and so we – champions of software development – must press on in the face of dreary complexity; we will not back down, we will not surrender, we will look that CRT/LCD screen in the pixels and say, “Untested units, you will not defeat me!”.
Diving into the thick of things, the most common question seems to be, “Why can’t I get code coverage for my entire class?!”. The trick here is to think like a runtime engine, and consider how you might journey through all possible testing paths. Now I never said it’s easy, but with a bit of practice (and 8 truck loads of patience) you’ll get there. Let’s look at some common cases. Read the rest of this entry »
I’m sure every Apex developer has had their Developer Org data interfere with their unit testing. Or perhaps you have coded unit tests that function perfectly within your Developer Org but when deployed to another Org fail because of a different, partial or empty database.
Of course as a developer this type on inconsistency within your work environment is extremely counter-productive. Initially I developed a methodology that did the job but wasn’t nearly as concise as I would have liked. More recently however I’ve developed a technical solution that is universal as well as quick to implement. Read the rest of this entry »