Test Class for the Apex Class with try Catch block fails

Question

I am trying to write a test class for the Apex Class with try - catch block and this is my first time coding test classes. The Apex Class is like below which has trycatch

public class updateCaseRecord {    
     @AuraEnabled
    public static void updateCheck(String caseId){
        String msg = '';
        try
        {
        List<Case> records = [select id,Status from Case WHERE Id = :caseId];
        for (Case record : records)
        {
            record.Status = 'Closed';
        }
        update records; 
        }
        catch(DmlException e) 
            {
               for (Integer i = 0; i < e.getNumDml(); i++) {
                    msg =+ e.getDmlMessage(i) +  '\n' ; 
                   System.debug('getDmlFieldNames=' + e.getDmlFieldNames(i));
                   System.debug('getDmlMessage=' + e.getDmlMessage(i));  
                }
                throw new AuraHandledException(msg);
            }
            catch(Exception e)
            {
            throw new AuraHandledException(e.getMessage());
            }
            finally { }      
    }}

And I wrote my test class like

@IsTest
public class updateCaseRecordTest {
@IsTest static void testIsUpdateCheck() {

    ID parentRecType = '012U0000000PqA9IAK';
    ID csRecType     = '012U0000000QGv4IAG'; 

    Account pa = new Account(Name='Test Parent Account', recordTypeId=parentRecType);
    insert pa;

    Account testAccount = new Account(Name='test', Industry='Biotech',Territory__c='EUR',BillingCity='Test',BillingCountry='Germany',ParentId=pa.id);
    insert testAccount; 

    Contact c = new Contact(LastName='Test',LeadSource='Customer Service',AccountId=testAccount.Id);
    insert c;

    Case newCase1 = new Case();
    newCase1.Subject = 'testStatusClosed';
    newCase1.Status = 'New';
    newCase1.Category__c = 'Inquiry';
    newCase1.Sub_Category__c = 'Other';
    newCase1.AccountId = testAccount.Id;
    newCase1.ContactId = c.id;
    newCase1.recordTypeId=csRecType;
    insert newCase1;


    Test.startTest();
try
    {
    updateCaseRecord.updateCheck(newCase1.Id);
    List<Case> lCases = [SELECT Id,Status,OwnerId FROM Case WHERE Id =: newCase1.Id];
    System.assertEquals('Closed', lCases[0].Status); 
    System.assertEquals(UserInfo.getUserId(), lCases[0].OwnerId);
    }

    catch(DMLException e) {
        System.assertEquals(e.getMessage(), e.getMessage());
    }

    Test.stopTest();   
}}

I thought I captured the try catch but when I run the test class it has only 57% code coverage and shows like below

Following one of the answers here

Answer 1

Exceptions are probably one of the harder things to test (or at least test "properly"). Like with most things, the design of the code being tested has a big impact on how easy or hard that code is to test.

To test this properly, I might break your SUT (System Under Test, i.e. the code of the class you've written) into two classes. One "parent" class to handle errors/exceptions, and one "child" class that inherits from the "parent" class to implement the behavior.

Something like

// The "parent" class remains mostly the same
// We make it "virtual" so we can inherit from it later
public virtual class UpdateCaseRecord {
    @AuraEnabled
    public static void updateCheck(String caseId){
        String msg = '';
        try{
            // We'll rely on child classes to override this method (and actually
            //   define its implementation)
            doWork(caseId);
        } catch(DmlException e) {
            for (Integer i = 0; i < e.getNumDml(); i++) {
                msg =+ e.getDmlMessage(i) +  '\n' ; 
                System.debug('getDmlFieldNames=' + e.getDmlFieldNames(i));
                System.debug('getDmlMessage=' + e.getDmlMessage(i));  
            }
            throw new AuraHandledException(msg);
        } catch(Exception e){
            throw new AuraHandledException(e.getMessage());
        }
        finally { }
    }

    // To override a method (which we will be doing), the method in the parent class
    //   needs to be either "virtual" or "abstract"
    public virtual void doWork(String caseId){}

    // I've made this an inner class because I think it makes the example clearer given
    //   the formatting options we have on SFSE.
    // This doesn't _need_ to be an inner class. It could be a completely separate class
    public class CloseCase extends UpdateCaseRecord{
        override public void doWork(String caseId){
            // If you have the recordId, you don't need a query to perform an update
            //List<Case> records = [select id,Status from Case WHERE Id = :caseId];

            // We can provide key=value pairs in the constructor of SObjects
            List<Case> records = new List<Case>{new Case(Id = caseId)};

            for (Case record : records){
                record.Status = 'Closed';
            }

            update records;
        }
    }
}

That should give you the same behavior you have now...but what's the point of adding that extra complexity and typing?

The answer is that it gives us a lot more flexibility in testing. Since we can inherit from the parent class, our test class can itself define a class that inherits from that parent class. What's more, we have basically complete control over what our special test class can do.

Test classes can have inner classes too, so...

@isTest private class MyTestClass{
    // When called, we want this inner class to throw a DML exception.
    // That's hard to do, normally, and not really appropriate to do in non-test code
    //   but here, we have complete control over what happens
    private class MyDMLExceptionTest extends UpdateCaseRecord{
        public override void doWork(String caseId){
            throw new DMLException();
        }

    @isTest
    void testDMLException(){
        // You could instead declare the type here to be UpdateCaseRecord, and that
        //   might, in fact, be better design.
        // This works for purpose of example just fine though.
        MyDMLExceptionTest testUnit = new MyDMLExceptionTest();

        Test.startTest();
        // Because MyDMLExceptionTest inherits from UpdateCaseRecord, we have access to
        //   the updateCheck method.
        // The updateCheck method contains the try/catch, and our test implementation ensures
        //   we throw one of those exceptions
        testUnit.updateCheck(null);
        Test.stopTest();

        // Don't forget to make assertions about the results of the test!
        // A test without assertions won't tell you if your method that adds 2 and 2
        //   erroneously gives you 5 as a result, but that's something you'd be interested
        //   in knowing.
    }
}

You can basically add as many inner classes as you need, so it's just rinse and repeat for other exceptions (and more) that you find yourself facing.

The other part of this is your test itself. Right now, you have no good way to know if your test caused an exception to be thrown or if that exception was handled.

In my tests that stress exception paths, I generally apply the following pattern.

@isTest
void myTest(){
    MyClass testUnit = new MyClass();

    // Not 100% sure if this needs to be defined outside the try/catch, but
    //   I think block scoping rules require it to be outside of the try/catch.
    // We need something to keep track of whether we encountered an exception or not
    //   when producing an exception is the expected result because just letting
    //   the exception remain uncaught would lead to a test failure.
    Boolean exceptionCaught = false;

    try{
        testUnit.myMethod();
    }catch(MyClass.MyException e){
        // Only set our variable if we encounter the exception we expected
        // This allows the assertion below to be useful
        exceptionCaught = true;
    }

    System.assert(exceptionCaught, 'Expected exception was not caught');
}

Answer 2

Now that I've gotten what I believe to be the "correct" way to design and test this out of the way, there is a simpler (but more crude) approach you could also take.

You can simply have a private variable (with the @testVisible annotation) to dictate when to throw an exception (and which one to throw).

public class updateCaseRecord {
    // private so that normal code can't set this variable
    // testvisible so that we can do so in tests
    @testVisible
    private String throwExceptionType;

    private Map<String, Exception> exceptionsMap = new Map<String, Exception>{
        'dml' => new DMLException(),
        'other' => new MathException() // normally thrown for things like divide by 0
    };

    @AuraEnabled
    public static void updateCheck(String caseId){
        String msg = '';
        try{
            // This is the operative bit
            if(exceptionsMap.containsKey(throwExceptionType)){
                throw exceptionsMap.get(throwExceptionType);
            }

            List<Case> records = [select id,Status from Case WHERE Id = :caseId];
            for (Case record : records){
                record.Status = 'Closed';
            }
            update records; 
        }
    // and the rest of the class remains unchanged

You'd then set that private, testvisible variable like you would any other variable.

updateCaseRecord testUnit = new updateCaseRecord();
testUnit.throwExceptionType = 'dml';

Et voila, one guaranteed exception, able to be crafted to your liking. Quick and easy to implement, hard to accidentally cause issues when it's being run for real, minimally invasive.

The price you pay though is that it's not great design. It can cover up issues that could be solved with better design.