Requisiti ragionevoli di copertura del test quando si tratta di un appaltatore?

Quando esegui il subappalto, spetta a te assicurarti che il codice venga scritto almeno funziona nel modo in cui ne hai bisogno. Per questo motivo, il tuo team dovrà scrivere alcuni test di accettazione automatici. Fornisci questi test al tuo subappaltatore, in modo che possano assicurarsi che il loro codice funzioni con esso.

Ogni volta che richiedi una copertura percentuale nei test delle tue unità, spetta a te fornire lo strumento che misurerà la copertura del codice. Non conosco l'ambiente in esecuzione (.Net, Java, Ruby, ecc.), Ma di solito sono disponibili più strumenti per misurare la copertura e non sono tutti uguali. È inoltre necessario specificare, o almeno accettare i parametri utilizzati (ad esempio esclusioni di copertura, tipo di copertura, ecc.).

Sarebbe ingiusto e improduttivo richiedere il test di:

• Classi / metodi generati (alcuni strumenti ORM generano classi, i componenti dell'interfaccia utente .Net generano classi e metodi, ecc.)
• Codice di cattura delle eccezioni a livello di sistema. Il codice può essere richiesto dalla lingua e dalle buone pratiche, ma se il test richiede l'hacking della piattaforma stessa, non vale la pena investire.

Non richiedere più subappaltatori di quanti ne faresti della tua stessa squadra. Se si desidera richiedere una determinata percentuale di test unitari come criterio di accettazione, fornire un intervallo del 70-80%. Se lo hanno battuto, fantastico. Considererei il 50% di copertura un minimo assoluto, con il 70% un requisito decente. Qualunque cosa al di sopra del 70% potrebbe costare di più, ma su questo avrai una mente migliore.

Solo una nota su parametri come la copertura del test. Sono solo numeri e chiunque può giocare con i numeri. Penso che il tuo intento sia buono, ma chiunque può giocare al sistema può farlo. Il numero di copertura è un'indicazione approssimativa della completezza del test, ma non della qualità del test. Nella mia esperienza, molti programmatori che non sono abituati a scrivere test di unità tendono a scrivere test di integrazione e semplicemente a eseguire l'applicazione attraverso il framework di test senza alcuna asserzione. Essenzialmente si stanno solo fornendo un punto di partenza per il passaggio da un debugger. Ci vuole tempo e allenamento per ottenere test unitari che siano utili.

Avrei bisogno di una consegna iniziale anticipata semplicemente per valutare l'efficacia dei test unitari e per aiutare a mettere a punto le tue aspettative e le loro. Ciò aiuterà entrambi a raggiungere la stessa pagina e a migliorare le consegne future.

Testivus sulla copertura del test - Dal Google Testing Blog:

Una mattina presto, un giovane programmatore chiese al grande maestro:

"Sono pronto a scrivere alcuni test unitari. Quale copertura del codice dovrei mirare? "

Il grande maestro rispose:

"Non preoccuparti della copertura, scrivi solo dei buoni test."

Il giovane programmatore sorrise, si inchinò e se ne andò.

Più tardi quel giorno, un secondo programmatore fece la stessa domanda.

Il grande maestro indicò una pentola di acqua bollente e disse:

"Quanti chicchi di riso dovrebbero mettere in quella pentola?"

Il programmatore, guardando perplesso, rispose:

"Come posso dirtelo? Dipende da quante persone hai bisogno di nutrire, da quanto sono affamate, da quale altro cibo stai servendo, da quanto riso hai a disposizione e così via. "

"Esattamente", disse il grande maestro.

Il secondo programmatore sorrise, si inchinò e uscì.

Verso la fine della giornata, è arrivato un terzo programmatore che ha posto la stessa domanda sulla copertura del codice.

"L'ottanta percento e non meno!" rispose il maestro con voce severa, battendo il pugno sul tavolo.

Il terzo programmatore sorrise, si inchinò e uscì.

Dopo quest'ultima risposta, un giovane apprendista si avvicinò al grande maestro:

"Grande maestro, oggi ho sentito rispondere alla stessa domanda sulla copertura del codice con tre risposte diverse. Perché?”

Il grande maestro si alzò dalla sedia:

"Vieni a prendere un tè fresco con me e parliamo di questo".

Dopo aver riempito le tazze con il tè verde fumante, il grande maestro iniziò:

"Il primo programmatore è nuovo e appena iniziato con i test. In questo momento ha un sacco di codice e nessun test. Ha una lunga strada da percorrere; concentrarsi sulla copertura del codice in questo momento sarebbe deprimente e abbastanza inutile. Sta meglio solo abituarsi alla scrittura e all'esecuzione di alcuni test. Può preoccuparsi della copertura più tardi.

Il secondo programmatore, d'altra parte, è abbastanza esperto sia in fase di programmazione che di test. Quando ho risposto chiedendole quanti chicchi di riso dovrei mettere in una pentola, l'ho aiutata a capire che la quantità di test necessari dipende da una serie di fattori, e lei conosce questi fattori meglio di me - è il suo codice dopo tutto . Non c'è una risposta semplice, semplice, ed è abbastanza intelligente da gestire la verità e lavorare con quello. "

"Capisco," disse il giovane apprendista, "ma se non c'è una sola risposta semplice, allora perché hai detto al terzo programmatore 'L'ottanta percento e non meno'?"

Il grande maestro ha riso così strong e strong che la sua pancia, la prova che ha bevuto più di un semplice tè verde, è caduto su e giù.

"Il terzo programmatore vuole solo risposte semplici - anche quando non ci sono risposte semplici ... e poi non le segue comunque."

Il giovane apprendista e il grande maestro brizzolato finirono di bere il loro tè in contemplativo silenzio.

Puoi trovare una misura più specifica. Per esempio. Copertura al 100% per metodi con complessità ciclomatica > = 5. Etc ...

Se si desidera un numero, viene spesso utilizzato l'80%. Infatti, dove lavoro attualmente, il nostro server di integrazione continua (Hudson) mostra una luce gialla per qualsiasi progetto su cui la copertura del test è inferiore all'80%.

La sfida qui è che garantire che una certa percentuale delle linee sia coperta dai test è molto diversa dall'assicurare che il codice sia testato in modo da ottenere una migliore manutenibilità.

Per prima cosa, uno strumento di copertura del codice può essere ingannato da un test che esercita il codice e termina con Assert.assertTrue(true) .

La preoccupazione meno dolosa è che un programmatore che non sa come scrivere buoni test non scriverà test al livello appropriato di granularità, il che può portare a una situazione in cui le future modifiche richiedono importanti cambiamenti nei test e i test diventano un onere per il refactoring, piuttosto che un aiuto.

Quindi, se volessi dare un numero, userei l'80%. Ma questo numero è utile solo quando si tratta di uno sviluppatore onesto che sa scrivere buoni test.