Determinare la quantità ottimale di test unitari?

Question

Determinare la quantità ottimale di test unitari?

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

0

Penso che potrei scrivere - too many unit tests.

Ad esempio, dire che stavo facendo un sistema di gestione dei corsi, e ho codificato una funzione per l'invio di corsi per conto di uno studente. Se le credenziali non valide sono specificate nella chiamata API, viene restituito un 401 proibito. Se uno studente tenta di inviare corsi di uno studente diverso, viene restituito un errore diverso. Se uno studente invia i propri corsi, è accettato ma in uno stato "in sospeso", in attesa di approvazione da parte dello staff. Se un membro della facoltà invia corsi per conto di uno studente, viene automaticamente accettato e anche inserito automaticamente lo stato "approvato".

Come puoi vedere, ci sono circa 4-5 diversi scenari qui, ciascuno con un risultato diverso.

Tendo a scrivere test per ogni scenario. Ciò significa che potrebbero essere necessari 10-15 minuti per codificare la funzione, ma poi altri 15 minuti - un'ora, per scrivere e superare tutti i test unitari. Possono essere anche 2 ore.

Ovviamente questo mi sta rallentando, e mi aspetto che fornirò risultati molto più velocemente. Ma a meno che non scrivo tutti quei test, mi sembra "sbagliato" e il codice potrebbe non funzionare come previsto.

Qual è la soluzione qui? Qual è la quantità giusta di test unitari da scrivere? Per ogni 1 ora di codifica, quanto tempo, max, dovrebbe essere speso per scrivere test per quella funzione?

tdd unit-testing productivity agile

posta Click Upvote 04.04.2016 - 21:55

fonte

3 risposte

Leggi altre domande sui tag tdd unit-testing productivity agile

Incluso il software GPL in progetto closed-code Come posso progettare efficacemente l'autenticazione della password per la crittografia nel mio progetto?

score 4 · Answer 1

Ognuno di quei risultati che hai descritto sono scenari di test validi. Il modo in cui sai che ogni comportamento è legato a un risultato diverso. Ciò rende ciascuno uno dei candidati migliori per i test.

Da un punto di vista della complessità ciclomatica, il fatto che ci siano esiti diversi per ogni test corrispondente a diversi stati del programma significa quasi certamente che testare percorsi diversi attraverso il codice, migliorando la copertura del codice di test.

Se stavi ripetendo ripetutamente lo stesso comportamento ripetutamente e asserendo lo stesso risultato, allora potrei essere preoccupato che tu stia scrivendo troppi test. Ma non se ogni test sta testando un comportamento e un risultato specifici.

score 1 · Answer 2

C'è sempre un compromesso tra creazione e testing, potrei creare un prodotto perfetto, tornare indietro tra 10 anni e sarà pronto .. e nessun manager accetterà mai quella stima (o il costo :))

Quindi devi essere pragmatico, i test unitari non catturano tutti i bug, quindi non dovresti provare a creare un ambiente di test unitario perfetto al 100% con una copertura del 100% del codice. Puoi passare il 20% del tempo a scrivere l'80% dei test e trascorrere il resto del tempo scrivendo i test di integrazione che devi anche fare.

Tuttavia, c'è una parte della tua domanda che spicca:

to write and pass all the unit tests.

Ora, il tempo impiegato per far funzionare il codice in modo che passi i test dovrebbe essere considerato il tempo trascorso nella fase di codifica iniziale. Puoi eliminare qualsiasi vecchio codice spazzatura e dire "finito!" ma non è davvero finito - hai solo posticipato qualche tempo di programmazione in un secondo momento (quando viene scoperto il bug) o su qualcun altro (che è peggio, aggiusta il tuo casino). Quindi non pensare mai che scrivere codice sia la sua fine, il tempo impiegato per correggere il codice evidenziato dai tuoi test conta come il tempo di codifica, non il tempo di test.

Quindi, per rispondere alla tua domanda. Preferisco i test di integrazione nel main, quindi non eseguo test unitari su tutto. Io tendo a testare solo le parti del codice che sono complesse o scomode. Quindi non proverei a limitare il tempo speso nel test, ma a dare la priorità a ciò che deve essere testato. Un metodo semplice può essere visivamente controllato per essere corretto se è abbastanza semplice, la sua scrittura inutile è un test unitario solo per un getter, ad esempio. Quindi puoi dedicare più tempo a dare ai metodi complessi il test che meritano, risparmiando il tempo impiegato per testare il banale e aumentare la qualità generale e la produttività.

score 0 · Answer 3

"Martello in un chiodo - se il legno si divide dovresti aver usato una vite"

Come fai a sapere se non stai scrivendo abbastanza prove? Se i bug compaiono più a monte che potrebbero essere stati catturati nella fase di test dell'unità, non hai scritto abbastanza test.

Ma a parte questo, mi rendo conto che sei ugualmente interessato allo sforzo che hai speso come intestazione di possibili bug. Se ti ritrovi a scrivere codice per coprire intervalli di parametri o combinazioni dello stesso, allora framework come NUnit possono portare via molto lavoro all'asino. Se invece sono casi aziendali in buona fede, allora basta mordere il proiettile e cifrare quanti ne hai bisogno. Non esiste una regola pratica per questo: alcuni codici possono essere estremamente veloci da scrivere ma difficili da testare e viceversa.