Esempio di test dell'unità di scrittura per un metodo

Question

Esempio di test dell'unità di scrittura per un metodo

#1 da (4 voti)
#2 da (3 voti)

2

Sto scrivendo unit test per un'applicazione iOS. Comprendo chiaramente i vantaggi della scrittura di unit test & TDD, ma sono confuso su quale tipo di test puoi scrivere per metodi come questo;

-(void)setCurrentView:(NSString *)view data:(NSString *)data
{
    if (!isEmpty(view)) {
        [Crashlytics setObjectValue:view forKey:kCurrentView];
        if (!isEmpty(data)) {
            [Crashlytics setObjectValue:data forKey:kCurrentViewData];
        }
    }
}

È scritto in objective C & Crashlytics è un'API di terza parte.

Possiamo passare NULL e amp; nil values & verifica che non generi alcuna eccezione
Oltre a questo possiamo verificare che i valori siano impostati correttamente (isEqual)

Altri casi di test che possiamo usare qui ..

Aggiorna Il metodo sopra non funziona come escluso. Chiamare il metodo di classe " setObjectValue " non sta inviando nulla alla dashboard Crashlytics. Devo chiamare il metodo instance in Crashlytics per farlo funzionare ..

[[Crashlytics sharedInstance] setObjectValue:view forKey:kCurrentView];

tdd unit-testing ios objective-c

posta Clement Prem 20.05.2015 - 15:11

fonte

2 risposte

3

Nonostante le altre risposte a questa domanda, in questo metodo c'è un sacco di comportamenti e quindi molte cose che potrebbero andare storte se non le testiamo. Ecco i casi che verificherei:

Quando la vista non è vuota e i dati non sono vuoti, sia la vista che i dati sono impostati nell'oggetto Crashlytics. Questo test è sufficiente per ottenere copertura informativa .
Quando la vista non è vuota ma i dati sono vuoti, solo la vista è impostata nell'oggetto Crashlytics.
Quando la vista è vuota ma i dati non sono vuoti, non viene impostato nulla. I casi fino a qui ci forniscono copertura della filiale .
Quando la vista è vuota e i dati sono vuoti, non viene impostato nulla. I casi fino a qui ci darebbero una specie di copertura dei parametri .
L'impostazione della vista utilizza la chiave prevista.
L'impostazione dei dati utilizza la chiave prevista.

Nota che esistono diversi tipi di "vuoto", che dovresti testare tutti. Esiste un po 'di esplosione combinatoria qui, quindi è possibile eseguire il loop su un array di tutti i valori vuoti (preferito) o selezionare un valore vuoto rappresentativo per i test primari sopra elencati, e quindi aggiungere alcuni test aggiuntivi per verificare che l'altro sia vuoto anche i valori funzionano, senza puntare a una copertura completa.

Insieme, questi casi formano una sorta di specifica per il metodo. Se si effettua il refactoring del metodo o si modifica una parte correlata del sistema, questi test ti avviseranno quando la specifica è stata violata.

Naturalmente, non vogliamo effettuare chiamate API effettive per questi test, dopotutto, stiamo solo testando che il nostro codice sia corretto, non che l'API funzioni come previsto. Sarebbe quindi saggio utilizzare un oggetto fittizio per questi test e utilizzare i membri degli oggetti piuttosto che le variabili globali (ad esempio, utilizzare un tipo di iniezione di dipendenza).

risposta data 21.05.2015 - 09:23

fonte

Leggi altre domande sui tag tdd unit-testing ios objective-c

Chiarimento sull'acquisizione / rilascio della semantica nella programmazione multithread Compilare e distribuire un programma C su un MCU che esegue un RTOS

score 4 · Accepted Answer

Il punto di test unitario sta testando le funzionalità del tuo codice in isolamento. Nella misura in cui il tuo codice è semplicemente un wrapper attorno a una libreria esterna, non ha alcuna funzionalità per il test dell'unità.

Potrebbe essere utile testare unitamente i valori NULL e nil, come suggerito.

Tuttavia, l'unità che prova la chiamata alla biblioteca non sembra utile. Supponiamo di aver impostato un sostituto fittizio per l'oggetto Crashlytics (non conosco l'obiettivo C, quindi non so esattamente come lo farebbe). Cosa dimostrerebbe?

Che hai chiamato con successo la libreria
Che hai passato nei dati ricevuti con il metodo.

Questi sono abbastanza banali, e in ogni caso saranno più che adeguatamente coperti dai test di integrazione.