function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Two Quick Test Method Questions

There is a particular line of code that seems to be tricky for me in test methods. I have used this in various triggers, most of which seem to cover this line of code automatically, without any intentional additional code; however, a couple of my test methods are not covering this line of code, and I am wondering if there is a technique for covering this. This can be problematic, especially in very small triggers, where this line of code could make or break the 75% coverage.

}Catch(Exception e){}

My second question is: Say you have a trigger that creates a new record when triggered; how would you go about querying that newly created record in a test method? I'm guessing there is a simple line of code to use, I just don't know that line of code.
Can anyone help me out? Thanks in advance!

I don't know about the second one... (but the trigger has a purpose to create a new record, and you know the purpose, so I suppose you know a reference key or something)


The first one, that was also my problem, but I found a trick to solve "a part of " the problem.


If you create or update a field in the try scope, you can run the testmethod as read-only user, so it will throw DMLException.



private static testmethod void test(){ User u = new User(Name = 'Test', ProfileId = (readonly profile id), (all other required fields)); System.runAs(u){ // your test code here } }


 Of course, if you throw the exception from the method, you need to catch it in your testmethod.





Few suggestions:


1. Try and put all the business logic in Apex Classes. Unit testing and code reuse becomes easier that way.

2. You can cause exception by using the Read Only profile as suggested by ThomasTT. Do think about the genuine error conditions and setup your test data accordingly. For e.g. it's usually not a good idea to save Invoices with negative amount.


For your second question again ThomasTT has pointed you in the right direction. If you can provide more details then we can help you further.



On the second question.


Your unit test should be specifying the new record or some part of it, or at the very least you know how the record will be created by your trigger so you should be able to search for the new record based upon parts of the new record that you know or can calculate.




Example;  Say your trigger is on Contact and upon a new contact being created your trigger creates a new useraccount__c record linked to it.

 You know that the username on the useraccount__c record is to be unique and it's to be generated based upon the contact's name (first inital_last name perhaps) and that record will be linked to the contact.


Your unit test will create a new contact, specifying the first and last name, which will cause your trigger to run.  The result will be your useraccount__c record linked to your contact. 

Your unit test then simply calls a query to find a useraccount__c record that has the appropriate username and is linked to the contact that your unit test just created.  If you find more then zero records then your unit test passed.