« 2013 Predictions On The Data Industry | Main | Turn a Salesforce Hyperlink into a Button: »

Apex Unit Test



I’ve been developing code on various platforms for years, but lately I’ve been working on Saleforce’s proprietary language apex.  If you know java then apex should not be that strange to you at all.  That is pretty much where the similarities end.  Being a cloud based company, Salesforce enforces all sorts of rules and limits on your code. You’ll quickly learn how to be a smarter developer when you have to think about these limits. 

 Salesforce requires that you have 75% coverage on all code you write.  If you fall below this number then you cannot deploy any of the code you have written.  Coverage just means that if you have piece of code that says “hello” you must test it and verify that it says hello.  If not, every line is counted against your overall number.  You cover your code by writing the infamous unit tests.

Rewind to last month and it is really easy to forget or ignore writing test cases.  You can only get away with this for so long before your coverage starts gradually depleting.  After much effort I did a good job addressing a lot of missing coverage.  One thing that became really evident is that I was failing to do a negative test.  A negative test is just what it sounds like.  You pass in junk data and expect a failure.  This proves that your code not only works, but it handles exceptions correctly.  Below I have some sample code that illustrates both a positive and a negative test case.


           static testMethod void testremoveFormulaFieldsSchema()



              //Negative Test of formula field schema

              Map<String, Schema.SObjectField> targetSchemaFieldMap = null;

              targetSchemaFieldMap = removeFormulaFieldsSchema(targetSchemaFieldMap);

              system.assert(targetSchemaFieldMap == null, 'We did not get a null schema ');


              //Positive Test of formula field schema

              targetSchemaFieldMap = Schema.SObjectType.Account.fields.getMap();

              targetSchemaFieldMap = removeFormulaFieldsSchema(targetSchemaFieldMap);

              system.assert(targetSchemaFieldMap != null, 'We failed to get the account schema ');



As you can see above I call the same method “removeFormulaFieldsSchema” in both scenarios but in the first test I am passing null as a parameter.  This will test our code on how I handle exceptions and I expect nothing back after the code is executed.  In the second example I would expect data to be returned to me.  I also included the actual method I was testing for clarity below.  These two tests gave me 100% coverage in my new method and I was a happy person.


       public static Map<String, Schema.SObjectField> removeFormulaFieldsSchema(Map<String, Schema.SObjectField> schemaMap)


         Map<String, Schema.SObjectField>  resultschema = new Map<String, Schema.SObjectField>();




                for(String field : schemaMap.keyset())



                  Schema.DescribeFieldResult desribeResult = schemaMap.get(field).getDescribe();


                  if (!desribeResult.isCalculated())


                    //Field is not a formula field so it is added to the schema.

                    Schema.SObjectField fieldS = schemaMap.get(field); 




                 return resultschema;

              }catch(exception e)


                     return schemaMap;



I hope this helps some apex coders out there to understand the importance of getting your unit test written with your new code.  It was a lot of effort to go back and fix all the omissions but it paid off.  I even found some bugs in the code that I didn’t expect.  Who would have thought that unit testing actually works and isn’t just some evil chore Salesforce imposes on us.


photo credit: <a href="">epospisil</a> via <a href="">photopin</a> <a href="">cc</a>

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.