Una delle principali novità della release Winter ’23 è l’introduzione di una classe Assert dedicata. Questo aggiornamento rende più facile trovare tutti i metodi di asserzione necessari in un unico posto. Diamo un’occhiata alle differenze con i metodi attuali per effettuare asserzioni nei tuoi test e come puoi iniziare a usarlo oggi.

Presentiamo la classe Apex Assert

Apex dispone già di metodi di sistema, come assert, assertEquals e assertNotEquals, per scrivere asserzioni nei test Apex. Questi metodi esistono da decenni e funzionano come previsto, anche oggi. Salesforce non prevede nell’immediato futuro di deprecare questi metodi di sistema. Tuttavia, consiglia di utilizzare la nuova classe Assert e cercare di utilizzarla nel codice esistente. La nuova classe Assert dispone di metodi aggiuntivi per scrivere asserzioni chiare e intenzionali. L’altro notevole vantaggio della nuova classe Assert è che se l’asserzione genera un’eccezione, è più facile da leggere e comprendere.

Utilizzo di Assert.fail() per restituire intenzionalmente un fatal error

Prima della nuova classe Assert, avresti utilizzato pattern, come quello qui sotto, per interrompere intenzionalmente l’esecuzione del codice nella tua classe di test e restituire un fatal error.

try {
Test.startTest();
SomeClass.someMethod();
System.assert(false, ‘Throw custom exception’); //Halt code execution and return fatal error
} catch (Exception ex) {
// Further assertions
}

Il codice sopra è meno leggibile. L’istruzione System.assert(false) rende meno ovvio che vogliamo fallire il codice intenzionalmente. Modifichiamo il codice precedente per utilizzare il nuovo metodo Assert.Fail().

try {
Test.startTest();
SomeClass.someMethod();
Assert.Fail(‘Exception expected during test’);
} catch (Exception ex) {
// Further assertions
}

Come puoi notare, diventa ovvio con la parola “fail” che vogliamo fallire l’esecuzione del codice su una riga specifica se non si è verificata l’eccezione prevista.

Utilizzo di Assert.isInstanceOfType() per asserire l’istanza dell’oggetto

Prendiamo un pattern di esempio di scrittura di asserzioni nel codice di test Apex per affermare che l’istanza dell’oggetto è del tipo specificato con il metodo System.assert.

try {
Test.startTest();
SomeClass.someMethod();
System.assert(false, ‘Throw custom exception’);
} catch (Exception baseException) {
// Assert the Exception type
System.assert(
baseException instanceof SomeClass.SomeCustomException, ‘Expected an instance of SomeException’);
}

Modificando il codice precedente per utilizzare la nuova classe Assert e utilizzando il metodo isIntanceofType(), vedremo che la leggibilità è molto migliorata.

try {
Test.startTest();
SomeClass.someMethod();
Assert.Fail(‘Throw custom exception);
} catch (Exception baseException) {
Assert.isInstanceOfType(baseException,
SomeClass.SomeCustomException,
‘Expected an instance of SomeCustomException’);
}

Suggerimento: si noti che il metodo Assert isInstanceOfType accetta il primo parametro come tipo effettivo, seguito dal tipo previsto e quindi dal messaggio personalizzato. Mentre per il resto dei metodi Assert, il primo parametro è il risultato previsto seguito dal risultato effettivo e quindi dal messaggio personalizzato.

Utilizzo di Assert.isNull() per affermare i valori null

Per aggiungere chiarezza al modo in cui si controllano i valori null nei test, sono stati introdotti i metodi Assert.IsNull() e Assert.isNotNull(). Diamo un’occhiata alle differenze con i metodi di sistema e come possiamo aumentare la leggibilità.

Il codice seguente usa System.assert e ha un’espressione per verificare se l’oggetto NON è nullo.

Opportunity opp = OpportunityService.getRecentClosedOpportunity();
System.assert(opp != null, ‘Expected the opportunity to not be null’);

Il codice precedente è corretto, ma poiché la classe Assert ora offre un metodo adatto per confrontare il valore null, può essere reso più leggibile come segue.

Opportunity opp = OpportunityService.getRecentClosedOpportunity();
Assert.isNotNull(opp, ‘Expected the opportunity to not be null’);

Utilizzo di Assert.areEqual() invece di System.assertEquals() per rendere più chiaro il codice

Il metodo Assert.areEqual è molto simile a System.assertEquals. Afferma che due valori sono uguali. Il vantaggio della nuova classe è che è più leggibile, e se le asserzioni non risultano corrette durante l’esecuzione del test, si ha un messaggio di errore più chiaro. Ecco un semplice esempio di confronto tra l’utilizzo di System.assertEquals e Assert.areEqual.

Il codice seguente utilizza System.assertEquals.

Account acc = new Account();
acc.Name = ‘Test Account’;
insert acc;
System.assertEquals(‘Test Account’, acc.Name, ‘Expected account name to be Test Account’);

Con Assert.areEqual, il codice sopra può essere modificato come di seguito. Si noti che è stato soltanto sostituito System.assetEquals con Assert.areEqual.

Account acc = new Account();
acc.Name = ‘Test Account’;
insert acc;
Assert.areEqual(‘Test Account’, acc.Name, ‘Expected account name to be Test Account’);

Utilizzo di Assert.isTrue() invece di System.assert() per rendere più chiaro il codice

A questo punto, si può notare come questi nuovi metodi abbiano nomi più precisi rispetto ai loro omologhi precedenti. Tuttavia, questo può creare un po’ più di confusione, System.assert() e Assert.isTrue() funzionano in modo simile, ma i loro nomi non sono esattamente gli stessi.

Il codice seguente usa System.assert per le asserzioni.

Boolean containsForce = ‘Salesforce’.contains(‘force’);
System.assert(containsForce, ‘Contains force’);

Utilizzando Assert.isTrue, il codice precedente viene modificato come mostrato di seguito, rendendo il codice più leggibile.

Boolean containsForce = ‘Salesforce’.contains(‘force’);
Assert.isTrue(containsForce, ‘Contains force’);

Nella classe Assert sono disponibili anche metodi equivalenti all’operatore NOT. Ad esempio, esiste Assert.isFalse() che afferma che la condizione è falsa. L’obiettivo con Assert.isFalse() è sostituire uno snippet di codice in uno scenario simile a System.assert(!containsForce) con la negazione iniziale. Assert.isFalse() chiarisce che la condizione deve essere falsa.

Puoi esplorare l’intero elenco dei metodi disponibili nella relativa documentazione.

Creazione di messaggi di errore efficaci

Come è possibile notare guardando gli snippet di codice precedenti, è stato utilizzato l’ultimo parametro facoltativo dei metodi Assert per aggiungere un messaggio di errore personalizzato. È buona norma scrivere messaggi di errore chiari in modo che, se il test fallisce, aiutino ad analizzarne la causa.

I nuovi metodi della classe Assert incoraggiano anche la creazione di messaggi di errore efficaci limitando l’ultimo parametro a una stringa. Il System.assert() accetta un oggetto per il messaggio e lo converte in una rappresentazione in stringa, spesso risultando meno utile per il debug dei test falliti. I nuovi metodi Assert richiedono esplicitamente una stringa. Quindi non è possibile usare un sObject o una mappa nei parametri del messaggio, per incoraggiare lo sviluppatore ad essere molto esplicito e pensare attentamente ai messaggi di errore.

Suggerimenti finali

È possibile che esista già una classe custom denominata “Assert”. Salesforce non impedisce di creare una classe denominata Assert, ma la presenza di tale classe può causare conflitti quando si utilizza la nuova classe Assert. In questi casi è possibile aggiungere il namespace System alla classe Assert. Ad esempio, si può scrivere System.Assert.areEqual invece di Assert.areEqual in modo da usare correttamente la nuova classe.

Conclusioni

La nuova classe System.Assert fornisce metodi che gestiscono tutti i tipi di asserzioni logiche e confronti. Quando si utilizza un metodo assert destinato a una condizione specifica, la leggibilità del codice migliora. E se l’affermazione si traduce in un’eccezione, è più facile da leggere e capire.

Share:

administrator