Come dovrei testare il mio codice TEST?

16

One of the few things that most software developers agree on is that you shouldn't rely on code to work correctly unless you test it. If you don't test it, it may have hidden bugs that are only going to cause you more work down the road.

Capisco come testare il mio codice normale, ma come dovrei testare il mio codice di test per assicurarmi che possa trovare e segnalare efficacemente gli errori quando sono presenti? personalmente sono stato abbastanza stupido da scrivere casi di test errati che passerebbero quando non dovrebbero avere, sconfiggendo così in primo luogo lo scopo dei miei test di scrittura. Fortunatamente, ho trovato e corretto gli errori in tempo, ma in base ai test mantra sembra che nessuna suite di test sarebbe completa senza avere il proprio set di test per assicurarsi che funzionasse.

Mi sembra che il modo migliore per farlo sarebbe quello di assicurarmi che il test fallisca con il codice bacato. * Se trascorro 2 minuti alternativamente aggiungendo bug al codice e assicurandomi che fallisca, dovrei avere un grado accettabile di fiducia che i test "funzionino". Questo mi porta alla mia seconda domanda: Quali sono i modi migliori per introdurre i bug per assicurarti che siano presi dai casi di test? Devo commentare solo a caso le dichiarazioni, assicurati che il ramo sbagliato di if-else viene eseguito negando la sua condizione e modifica l'ordine di esecuzione del codice con effetti collaterali, ecc., finché non sono soddisfatto che i miei test cattureranno la maggior parte bug comuni? In che modo gli sviluppatori professionisti convalidano che i loro test fanno effettivamente quello che dovrebbero fare? Assumono solo che i test funzionino o si prendano il tempo per testarli? Se sì, come fanno a testare i test?

Non sto suggerendo che le persone debbano spendere così tanto tempo a testare i loro test e poi a testare i test per non aver mai scritto il vero codice, ma ho fatto cose abbastanza stupide che mi sembra di poter trarre beneficio da un po 'di "meta-test", ed era curioso del modo migliore per farlo. : D

* Potrei controllare se il test passa durante il test del codice "bug-free", ma usare il codice come una specifica per il test sembra piuttosto indietro ...

    
posta Gordon Gustafson 23.07.2012 - 23:24
fonte

4 risposte

12

Il flusso standard per TDD è:

  1. Scrivi un test in errore. (Red)
  2. Apporta la modifica più piccola al codice che consente di passare (verde)
  3. Refactor (Mantenerlo verde)

Il test per i test in questo caso è il passaggio 1: accertati che il test non abbia esito positivo prima di apportare modifiche al codice.

Un altro test che mi piace è se puoi eliminare del codice e implementarlo di nuovo in un modo diverso, e i tuoi test falliscono dopo l'eliminazione ma funzionano con un algoritmo diverso.

Come con tutte le cose, non esiste un proiettile magico. Dimenticare di scrivere un test richiesto è altrettanto facile per uno sviluppatore fare come dimenticare di scrivere il codice. Almeno se stai facendo entrambe le cose, hai il doppio delle opportunità per scoprire la tua omissione.

    
risposta data 24.07.2012 - 10:16
fonte
6

Un approccio è uno strumento come Jester :

Jester makes some change to your code, runs your tests, and if the tests pass Jester displays a message saying what it changed

    
risposta data 23.07.2012 - 23:33
fonte
4

Test per i test? Non andare su quella strada. Allora probabilmente avrai bisogno di test per test per test e poi test per test per test per test ... dove ti fermi?

Il flusso di test usuale va così e, come sviluppatore, trascorrerai la maggior parte del tuo tempo sui punti 1-3:

  1. Codice
  2. Test di unità
  3. Test di integrazione
  4. Sistema / altro automatizzato
  5. QA / testers umani

If I spend 2 minutes alternately adding bugs to the code (...)

Il tuo codice alla fine "crescerà" i suoi bug, non perdere tempo a introdurli a mano. Per non parlare, è una cosa che sapevate in anticipo davvero un insetto? Verranno dei bug, non me ne preoccuperei.

Should I just randomly comment out statements, make sure the wrong branch of an if-else gets run by negating its condition (...)

Questo è in realtà un approccio praticabile per verificare se effettivamente collaudi ciò che pensi di fare. Non penso che sia sempre così buono in quanto soffre dello stesso problema di "prova per test per prova ..." cosa: quando smetti di alterare il codice di conoscenza del codice che stai testando 100 % funziona?

È inoltre utile ricordare i consigli pragmatici del programmatore di tutti i tempi: non ne avrai bisogno . Sii agile, scrivi test e codice per veri bug, invece per quelli ipotetici che potrebbero o non potrebbero apparire.

    
risposta data 23.07.2012 - 23:37
fonte
2

Per costruzione, codice funzionale e codice di prova vengono testati l'uno contro l'altro. Un problema rimane: il caso di bug in modalità comune, quando un bug nel codice funzionale è nascosto da un bug nel codice di test. TDD non è immune da questo effetto. Questo è il motivo per cui il test viene solitamente eseguito a più livelli da persone diverse al fine di ridurre questa probabilità.

    
risposta data 24.07.2012 - 10:29
fonte

Leggi altre domande sui tag