The Silver Lining

Lessons & Learnings from a salesforce certified technical architect.

Posts Tagged ‘Testing

Salesforce: System.Assert vs System.AssertEquals

with 7 comments

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:

System.assertEquals(var1, var2);

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)

Advertisements

Written by Wes

September 7, 2010 at 8:03 pm

Salesforce Unit Tests & Code Coverage

with 13 comments

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 »

Written by Wes

February 4, 2010 at 6:06 pm

%d bloggers like this: