Come garantire che un nuovo Test unità sia per il caso di test corretto? [duplicare]

Question

Come garantire che un nuovo Test unità sia per il caso di test corretto? [duplicare]

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

0

Durante la scrittura di un test unitario per uno scenario che si ritiene sia già coperto, ovvero, la prima esecuzione del test sarebbe verde, che cosa è una buona guida per assicurarsi che stia effettivamente testando il caso di test corretto, e non verificare che "sempre" passi, o passi per ragioni che non hanno nulla a che fare con il caso di test preso in considerazione?

Credo che la migliore pratica sia quella di cambiare la tua classe sotto test, in modo che fallisca prima, e quindi rimuovere il bug intenzionale per vedere se diventa verde, tuttavia quella spiegazione è troppo vaga. All'estremo, potrei semplicemente fare in modo che il mio costruttore lanci un'eccezione per ottenere un test rosso, quindi rimuovere il lancio per renderlo verde. So che il cambiamento di rottura dovrebbe essere qualcosa di "vicino" allo scenario sotto test, ma non sono sicuro di come lo si possa definire come una corretta linea guida che i miei ragazzi potrebbero seguire.

object-oriented unit-testing

posta Kindread 05.03.2015 - 21:40

fonte

2 risposte

1

Anche se è giusto non iniziare a testare i test, la capacità di un test di fallire è cruciale. Un test che non può fallire non solo è inutile, ma indica anche che ...

ha fatto errori logici
volevo solo fare dei test rapidi senza pensarci o
sta testando la lingua (ad esempio unsigned > = 0) o logica generale ( true || false )

Se hai già implementato il codice, ti preghiamo di non far fallire il test bloccando il programma . Il seguente test fallirà sempre, anche se si tratta di una tautologia.

#include <gtest/gtest.h>

TEST(test,testcase) {
    throw 1;
    EXPECT_TRUE(true);
}

int main(int argc, char ** argv) {
    ::testing::InitGoogleTest(&argc,argv);
    return RUN_ALL_TESTS();
}

(Forse ci sono framework di test in cui questo test dovrebbe ancora passare, ma ce n'è almeno uno in cui ti dà una falsa sicurezza.)

Invece basta scrivere una rapida "implementazione vuota" che abbia la stessa interfaccia e semplicemente non faccia nulla. A questo punto, quando tutti i test falliscono, si rimuove il dummy con l'implementazione reale.

risposta data 05.03.2015 - 23:36

fonte

Leggi altre domande sui tag object-oriented unit-testing

Esempi di sistemi operativi in grado di servire richieste http che non supportano la barra diretta per il separatore di directory REST e vincoli di chiave esterna

score 3 · Accepted Answer

what is a good guideline to ensure that it is in fact testing the proper test case

Questo ricade sul vecchio "chi mette alla prova i test?" linea di pensiero.

E in generale, nessuno può testare i test. I test unitari si sono dimostrati così di successo in parte perché sono abbastanza piccoli da poter essere implementati senza errori. Una buona linea guida è che un altro sviluppatore può guardare il test e dire "sì, sembra che prova quello che dice che fa".

Questo è abbastanza per cogliere la maggior parte dei problemi. Il resto fa parte di un buon approccio a livelli alla qualità del software. Anche se il test è sbagliato, il controllo di qualità o il test di accettazione da parte dell'utente possono aiutare a cogliere le cose che sfuggono al test. Ciò riduce il rischio che un bug scappi in produzione ad un livello accettabile.