Write Comprehensive Tests

• calculateInterestRate — all three tiers plus boundaries. ✓
• calculateMonthlyPayment — never directly tested yet, only indirectly through the trigger test. ✗
• validate — several rejection scenarios, one acceptance scenario. ✓
• determineStatus (inside the trigger) — Pre-Approved and mixed scenarios tested. Manual Review and Declined individually? Only as part of the mixed test.

@isTest
static void monthlyPaymentCalculatesCorrectly() {
    LoanCalculationService service = new LoanCalculationService();
    Decimal payment = service.calculateMonthlyPayment(10000, 6.5, 60);

    // A known correct value for this exact input, calculated independently ahead of time
    System.assertEquals(195.66, payment.setScale(2));
}

Testing calculateMonthlyPayment directly — rather than only indirectly through the trigger test — means a bug in the formula itself gets caught precisely, instead of only surfacing as a vaguer failure somewhere inside a larger trigger test.

@isTest
static void creditScoreOf600GetsManualReview() {
    Loan_Application__c app = LoanTestDataFactory.createApplication(10000, 50000, 600);
    insert app;

    Loan_Application__c saved = [SELECT Status__c FROM Loan_Application__c WHERE Id = :app.Id];
    System.assertEquals('Manual Review', saved.Status__c);
}

@isTest
static void creditScoreOf599GetsDeclined() {
    Loan_Application__c app = LoanTestDataFactory.createApplication(10000, 50000, 599);
    insert app;

    Loan_Application__c saved = [SELECT Status__c FROM Loan_Application__c WHERE Id = :app.Id];
    System.assertEquals('Declined', saved.Status__c);
}

Exactly the boundary-testing habit from Lesson 2, now applied to the trigger's status-decision logic specifically — 600 and 599 are where a real off-by-one bug in determineStatus would actually hide.