ragionevoli esigenze di copertura dei test quando si tratta di un imprenditore?

Question

Stiamo esternalizzazione del lavoro da uno sviluppatore esterno, quindi sono impegnato a scrivere un contratto su ciò che costituisce un risultato finale.

Finora ho bisogno che il codice viene fornito con test automatizzati.

Ma, che cosa è un modo ragionevole per specificare dettaglio di prove di up-front nel contratto in modo misurabile?

Sono restio a dire "copertura del codice 100%" perché è stato stabilito abbastanza spesso che il 100% è piuttosto insignificante, ei rendimenti decrescenti di cui sopra circa il 70-80% sarebbe probabilmente solo essere spingendo verso l'alto i costi inutilmente, e, eventualmente, anche spingendo verso l'alto la complessità di certe cose che altrimenti potrebbero essere molto semplice.

Internamente abbiamo praticamente lasciare fino ai nostri sviluppatori di decidere il livello di test necessari, sulla base della loro intuizione e l'esperienza. Con un imprenditore però c'è un prezzo fisso che deve essere concordato in anticipo e abbiamo bisogno di un modo per far rispettare un certo livello di qualità.

Qualche suggerimento o lettura consigliata la materia sarebbe apprezzato!

Answer 1

Quando subappalto fuori, spetta a voi per assicurare il codice in fase di scrittura di almeno funziona il modo in cui avete bisogno di. Per questo motivo, il team avrà bisogno di scrivere alcuni test di accettazione automatizzati. Fornire questi test al subappaltatore, in modo che possano assicurarsi che i loro lavori di codice con esso.

Ogni volta che avete bisogno di percentuale di copertura nei vostri test di unità, spetta a voi per fornire lo strumento che sarà misurando la copertura del codice. Non so l'ambiente è in esecuzione (.Net, Java, Ruby, etc.), ma ci sono di solito più di uno strumento a disposizione per misurare la copertura, e non sono tutti uguali. È inoltre necessario specificare, o almeno accetta i parametri utilizzati (vale a dire le esclusioni di copertura, tipo di copertura, ecc.).

Sarebbe ingiusto e improduttivo di richiedere il test di:

• Le classi generate / metodi (alcuni strumenti ORM generano classi, componenti UI Net generano classi e metodi, ecc.)
• un'eccezione a livello di sistema di cattura del codice. Il codice può essere richiesto dal linguaggio, e la buona pratica, ma se il test si richiede l'hacking della piattaforma stessa, non vale la pena l'investimento.

non richiedono più dei vostri subappaltatori di quanto si farebbe della propria squadra. Se avete intenzione di richiedere una certa percentuale di unit test come criterio di accettazione, di fornire una gamma come 70-80%. Se hanno battuto esso, grande. Vorrei prendere in considerazione il 50% di copertura un minimo assoluto, con il 70% un requisito decente. Tutto ciò al di sopra del 70% può costare di più, ma dovrete avere una migliore pezzo di mente su di esso.

Solo una nota su metriche quali copertura di test. Sono solo numeri, e chiunque può giocare con i numeri. Credo che la vostra intenzione è buona, ma chi vuole ingannare il sistema ci riesco. Il numero di copertura è un'indicazione approssimativa del completezza del test, ma non il qualità del test. Nella mia esperienza, molti programmatori che non sono abituati a scrivere unit test tendono a test di integrazione di scrittura, e si limita a eseguire l'applicazione tramite il framework di test senza affermazioni di sorta. Essenzialmente sono solo fornendo loro un punto di lancio per scorrere con un debugger. Ci vuole tempo e formazione per ottenere test di unità che sono utili.

I richiederebbe una consegna anticipata prima semplicemente per valutare l'efficacia del loro test di unità, e per contribuire a mettere a punto sia le vostre aspettative e la loro. Che vi aiuterà entrambi a ottenere sulla stessa pagina, e rendere le future consegne migliori.

Answer 2

Testivus sulla copertura di test - Dal blog di Google Testing:

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

“Sono pronto a scrivere alcuni test di unità. Cosa copertura del codice dovrei puntare?”

Il grande maestro ha risposto:

“Non ti preoccupare per la copertura, basta scrivere alcuni test buoni”.

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

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

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

“Come molti chicchi di riso dovrebbero mettere in quella pentola?”

Il programmatore, perplessa, ha risposto:

“Come posso dire? Dipende da quante persone hai bisogno di mangime, quanta fame sono, quali altri alimenti si sta servendo, quanto il riso che avete a disposizione, e così via “.

“Esattamente,” disse il grande maestro.

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

Verso la fine della giornata, è venuto un terzo programmatore e ha chiesto la stessa domanda sulla copertura del codice.

“L'ottanta per cento e non meno!” Il maestro rispose con voce severa, battendo il pugno sul tavolo.

La terza programmatore sorrise, si inchinò, e se ne andò.

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

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

Il grande maestro si alzò dalla sedia:

“Come Get Some tè fresco con me e parliamo a riguardo”.

Dopo aver riempito le loro tazze con il fumo di tè verde caldo, il grande maestro ha cominciato:

“Il primo programmatore è nuovo e appena iniziato con il test. In questo momento lui ha un sacco di codice e nessun test. Ha una lunga strada da percorrere; concentrandosi sulla copertura di codice in questo momento sarebbe deprimente e del tutto inutile. E 'meglio solo abituarsi a scrivere ed eseguire alcuni test. Egli può preoccuparsi di una copertura più tardi.

Il secondo programmatore, d'altra parte, è piuttosto un'esperienza sia in programmazione e test. Quando ho risposto chiedendole il numero di chicchi di riso dovrei mettere in una pentola, aiutai rendersi conto che la quantità di test necessario dipende da una serie di fattori, e lei lo sa quei fattori meglio di me - è il suo codice dopo tutto . Non esiste una sola, semplice, risposta, e lei è abbastanza intelligente per gestire la verità e lavoro con quello “.

“Capisco,” disse il giovane apprendista, “ma se non esiste un unico semplice risposta, allora perché vi dico la terza programmatore‘ottanta per cento e non meno’?”

Il grande maestro rise così forte e forte che la sua pancia, prova che ha bevuto più di tè verde, si lasciò su e giù.

“Il terzo programmatore vuole solo risposte semplici -., Anche quando non ci sono risposte semplici ... e poi non li seguono in ogni caso”

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

Answer 3

Si può trovare con più misura specifica. Per esempio. copertura del 100% per i metodi con la complessità ciclomatica> = 5. Etc ...

Answer 4

Se volete un numero, l'80% è usato spesso. In realtà, dove lavoro attualmente il nostro server di integrazione continua (Hudson) visualizza una luce gialla per ogni progetto sul quale la copertura di test è inferiore all'80%.

La sfida è che assicurare che una certa percentuale delle linee sono coperti da test è molto diversa da quella che il codice viene testato in un modo che consente un migliore manutenibilità.

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

La preoccupazione meno dannoso è che un programmatore che non sa come scrivere buoni test non scriveranno i test al livello appropriato di granularità, che può portare a una situazione in cui i futuri cambiamenti richiedono grandi cambiamenti nei test, e la prove di diventare un peso per refactoring, piuttosto che un aiuto.

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