Posts Tagged ‘unit tests’
Salesforce: Different percentage unit test code coverage in different environments
Spot the difference.
Many people are finding that their tests are reporting different degrees of test-coverage in different environments. There are a few things to check if you are getting inconsistent results but there’s a new bug in the wild. Before you assume you have the bug make sure that you’ve:
- ‘Run All Tests’ in each environment. This will tell you a few things viz.
- Perhaps there are tests failing that are bringing coverage in that environment down.
- There are some tests that only fail when run in the browser e.g. MIXED_DML_EXCEPTION will not rear it’s head through the IDE.
- Click the ‘Compile all classes’ link above the Setup > Develop > Apex Classes view. I’m not sure when this lil’ bugger first appeared but it’s darn useful. Essentially it makes sure that all the dependencies in your code are fulfilled e.g. if page A uses controller B that in turn refers to utility class C it’ll make sure each of those pieces exist and work (as far as compilation goes at least).
- Double-check your test classes to make sure they’re not data dependent. If they are and you have different types/amounts of data in your respective environments it’s 100% feasible that the test coverage will be different.
Now if you’ve checked all of the above you might have been afflicted by a new bug which, for some reason, counts braces, whitespace (and more!) as being uncovered by your tests. This is preposterous of course and to fix it simply remove all test history from the deranged environment. Re-running the test and/or deploying them should now be back to normal!
Salesforce: System.Assert vs System.AssertEquals
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)
Unit Test Data Consistency
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 »
The Silver Lining 