Test di integrazione Object Oriented

Test di integrazione in ambienti object oriented

Tramite questa tipologia di testing andiamo a testare l’interazione tra classi (quando una classe utilizza un’altra classe). È necessario testare massicciamente le sequenze di metodi poiché determinati bug vengono individuati solo quando si verificano le invocazioni di determinate sequenze. Le sequenze di metodi da considerare sono molteplici quindi è necessario saper individuare e testare solo quelle significative.

Metodi per individuare e testare le sequenze di metodi significativi

Al fine di individuare e testare le sequenze di metodi significativi si possono usare due approcci che sono:

• Metodo delle pre e post condizioni
• Metodo basato sulla macchina a stati (state base machine)

Il metodo delle pre e post condizioni

Pre-condizione: predicato che deve essere verificato prima dell’invocazione di un metodo, solitamente viene verificato dal chiamante ma ci sono approcci di programmazione (defence programming) in cui viene verificato sia dal chiamato che dal chiamante.

Post-condizione: predicato che deve essere vero dopo l’invocazione di un metodo, rende conto di cosa è cambiato dopo l’esecuzione del metodo. Le post-condizioni sono scritte in linguaggio naturale (inglese) oppure in OCL, o attraverso JML. Una sequenza di metodi può essere espressa dalla tripletta (m1, m2, C), dove C sta ad indicare la condizione che può essere:

• TRUE: Sta ad indicare che m2 può essere sempre eseguito immediatamente dopo m1;
• FALSE: Sta ad indicare che m2 non può essere eseguito immediatamente dopo m1;
• PREDICATO: Sta ad indicare le condizioni che devono verificarsi affinché m2 possa essere invocato subito dopo m1.

Criteri di copertura per le sequenze di metodi

Quindi, dopo aver definito le sequenze di metodi si possono definire i criteri di copertura utili per stabilire quali sequenze testare, questi criteri sono:

• ALWAYS TRUE COVERAGE: Si prendono in considerazione le triplette in cui la condizione è sempre TRUE;
• ALWAYS/POSSIBLE TRUE COVERAGE: Si prendono in considerazione le triplette in cui la condizione è sempre TRUE o può esserlo a seconda del valore assunto dal predicato. Per quanto riguarda il predicato C, se questa è una (compound conditions) si prende in considerazione una sola disgiunzione (compound);
• ALWAYS/POSSIBLE TRUE COVERAGE PLUS: Si adotta la stessa regola di prima andando però a considerare tutte le disgiunzioni (compound) della condizione;

Criteri per il test di robustezza

Inoltre, esistono altri criteri che vengono usati per effettuare il test di robustezza, ovvero per analizzare il comportamento del sistema (come lo gestisce) nei casi in cui vengano invocate sequenze di metodi non ammesse, questi criteri sono:

• ALWAYS FALSE COVERAGE: Prendiamo in considerazione tutte le triplette in cui la condizione è sempre FALSE;
• ALWAYS/POSSIBLE FALSE COVERAGE: Prendiamo in considerazione tutte le triplette in cui la condizione è sempre FALSE o può esserlo a seconda della condizione, si considera una sola disgiunzione della condizione;
• ALWAYS/POSSIBLE FALSE COVERAGE PLUS: Si usa la stessa regola di prima andando però a considerare tutte le disgiunzioni della condizione.

Infine, facciamo riferimento all’ultimo criterio che ingloba tutti i precedenti. Il testing costa, quindi, quando considero le triplette faccio in modo da coprire quante più triple possibili con un unico caso di test e cercando di ridurre il numero di invocazioni di metodi. Per realizzare questo posso usare degli accorgimenti che prevedono di individuare le sequenze in questo modo: considero (m1, m2, T) quindi poi considero (m2, m3, T) poi (m3, m4, T) e così via.