C'è qualche valore nello scrivere un test unitario che è un sottoinsieme di un altro test?

Naviga le tue risposte
14

Per dare un esempio un po 'forzato, diciamo che voglio testare che una funzione restituisca due numeri e che la prima sia più piccola della seconda: 

def test_length():
    result = my_function()
    assert len(result) == 2

def test_order()
    a, b = my_function()
    assert a < b

Qui, se test_length fallisce, anche test_order avrà esito negativo. È consigliabile scrivere test_length o saltarlo?

EDIT: si noti che in questa situazione, entrambi i test sono per lo più indipendenti l'uno dall'altro, ognuno può essere eseguito in isolamento, oppure possono essere eseguiti in ordine inverso, non importa. Quindi nessuna di queste precedenti domande

è un duplicato di quello sopra.

    
posta Mihai 12.01.2015 - 16:24
fonte

4 risposte

28

Ci può essere un valore, ma questo è un po 'un odore. O i tuoi test non sono ben isolati (dal momento che test_order mette realmente alla prova due cose) o sei troppo dogmatico nel test (facendo due test per testare la stessa cosa logica).

Nell'esempio, vorrei unire i due test insieme. Sì, significa che hai più asserzioni. Peccato. Stai ancora testando una singola cosa: il risultato della funzione. A volte nel mondo reale ciò significa fare due controlli.

    
risposta data 12.01.2015 - 16:34
fonte
5

I tuoi test dovrebbero essere espliciti. Non è completamente dedotto che se text_length fallisce, test_order fallisce.

Non sono sicuro di come va in Python che hai postato, ma se len(result) è 3 allora il primo fallirà ma il secondo potrebbe passare (e se non in Python, quindi in lingue come JavaScript di sicuro ).

Come hai detto, vuoi verificare che la funzione restituisca due numeri e che siano in ordine. Due test è.

    
risposta data 12.01.2015 - 16:34
fonte
2

L'unico valore di test_length qui è che, se tutto passa, la sua stessa presenza indica che "lunghezza" è stata testata.

Quindi non è assolutamente necessario avere entrambi questi test. Mantieni solo test_order , ma considera di rinominarlo test_length_and_order .

Per inciso, trovo l'uso di nomi che iniziano con test un po 'maldestri. Sono un strong sostenitore dei nomi dei test che descrivono effettivamente la condizione che stai affermando.

    
risposta data 12.01.2015 - 20:41
fonte
1

Lascerei questi test separati se è così che si sono evoluti. Sì, è probabile che test_order fallisca ogni volta che test_length lo fa, ma sicuramente sai perché.

Sarei anche d'accordo che se il test_order è apparso per primo e hai trovato un errore verificabile era che il risultato non erano probabilmente due valori, aggiungendo quel controllo come assert e rinominando il test in test_length_and_order ha senso .

Se dovessi controllare anche i tipi di valori restituiti erano interi, includerei quello in questo test dei risultati "omnibus".

Ma nota ora che hai una batteria di test per il risultato di my_function() . Se ci sono più contesti (o, più probabilmente, più parametri) per testare questo, ora può essere una subroutine per testare tutti i risultati da my_function() .

Tuttavia, quando scrivo test unitari, normalmente collaudo i casi limite e quelli negativi da un buon input e output normale (in parte perché la maggior parte dei miei test "unitari" sono spesso mini test di integrazione) e spesso con affermazioni multiple, che sono solo suddivisi in test separati se falliscono nei modi in cui trovo di volere più informazioni senza eseguire il debug.

Quindi probabilmente inizierei con i tuoi test separati ed espandi test_length a test_length_and_types e lasciamo test_order separati, supponendo che quest'ultimo sia visto come "normale elaborazione".

    
risposta data 15.01.2015 - 02:21
fonte

Leggi altre domande sui tag

Esiste un modo più semplice per testare la convalida degli argomenti e l'inizializzazione dei campi in un oggetto immutabile? Quantificare il valore del refactoring in termini commerciali [duplicato]