Devo richiedere un test unitario ai programmatori? [chiuso]

Lavoro in un luogo in cui acquistiamo molti progetti IT. Attualmente stiamo producendo uno standard per i requisiti di sistema per la richiesta di progetti futuri. In questo processo, stiamo discutendo se possiamo richiedere o meno test di unità automatizzati dai nostri fornitori.

Sono fermamente convinto che un adeguato test automatico delle unità sia l'unico modo per documentare la qualità e la stabilità del codice. Tutti gli altri sembrano pensare che il test unitario sia un metodo opzionale che riguarda solo il fornitore. Pertanto, non faremo alcuna richiesta di test di unità automatizzati, test continui, rapporti di copertura, ispezioni di test di unità o simili. Trovo questa politica estremamente frustrante.

Sono totalmente fuori linea qui?

Per favore, forniscimi degli argomenti per qualsiasi opinione.

Sono fermamente convinto che un adeguato test automatico dell'unità sia l'unico modo per documentare la qualità e la stabilità del codice.

Il fatto è che non si otterrà (o molto raramente almeno) un adeguato test automatico dell'unità forzandolo sulle persone. Questo è un buon modo per ottenere test di merda e aumentare i costi dei progetti.

Personalmente, guarderei alla domanda o allo SLA che implica qualità; indipendentemente da come viene realizzato. 10 anni fa i test unitari erano alquanto rari. Non vuoi ammanettare i tuoi fornitori tra 10 anni quando avremo metodi migliori per garantire la qualità, ma la tua politica obsoleta richiede loro di usare alla vecchia maniera.

Personalmente penso che nel tuo caso dovresti pensare invece in termini di test di accettazione:

• Hai una scatola nera che ti viene data e ti aspetti che si comporti in un certo modo.
• Non pagherai fino a quando non lo farà.
• Scrivi unit test che esercitano il comportamento che devi vedere e, se falliscono, devono ripararlo.

Si noti inoltre che questa è una questione di fiducia. Se non ti fidi del tuo fornitore, devi procurarti il ​​codice sorgente, controllarlo e compilarlo tu stesso. Qualsiasi cosa meno di quella media che almeno la fiducia di loro un po ' .

Sono fermamente convinto che un adeguato test automatico dell'unità sia l'unico modo per documentare la qualità e la stabilità del codice.

Mi sorprende quanto sia comune questo pensiero. Automatizzato, si. Test unitario (solo), no. I test automatizzati del software offrono molto di più dei soli test unitari. Che dire di integrazione, sistema, funzionale, QA? Per alcuni motivi la gente tende a pensare: "Ok, quindi abbiamo dei test unitari adeguati. Fatto con i test, chiamalo venerdì sera!" . Il test unitario è solo l'inizio.

Comunque, torniamo sull'argomento. Sono d'accordo con gli altri dicendo che forzare qualcosa su qualcuno probabilmente produrrà risultati opposti a quelli desiderati. Non si sa mai come funziona il team, forse hanno ottenuto un reparto di test del valore di milioni di dollari e non hanno mai scritto test di unità singole.

Al mio primo lavoro lavoravo in un posto in cui avevamo 0 test unitari (eravamo un gruppo di ragazzi che lanciavano cose più o meno serie). Che ci crediate o no, ha funzionato. Certo, a nessuno è stato confidato il motivo per cui questo bug è stato corretto, o cosa ha risolto questa correzione, ma ha funzionato. Ci sono stati momenti in cui alcuni bug assolutamente casuali venivano fuori, mamazza da baseball e rischio di bruciare l'appartamentoalcune ore extra possono fare miracoli. Forse i tuoi fornitori usano tecniche simili ?

Dubito fortemente che la tua direzione sarà disposta a pagare per i test unitari adeguati in un contratto. Il corretto test unitario costa tanto quanto il codice che testano, ma dà poco valore percepito all'utente finale in modo che non vengano considerati ugualmente preziosi. Nessuna azienda di sviluppo di qualità sarà disposta a dedicare gli sforzi di sviluppo a test unitari per un costo inferiore rispetto ad altre parti, poiché non sono dannosi per il lavoro, ma possono trovare di più 2 contratti che richiedono lo stesso tempo senza requisiti di test unitari.

Prove unitarie impegnative aumenteranno probabilmente le tue quotazioni ricevute a un livello irragionevole, e sarà probabilmente la prima concessione fatta per ottenere un prezzo più basso.

Il costo di non avere unit test dipende da quanto estenderete / supporterete voi stessi il codice. Anche ispezionare parti del codice per avere un'idea della qualità sarebbe importante.

Se stai solo acquistando i progetti in modo da poterli utilizzare come una libreria di terze parti e non credi che li modificherai, il rischio di un codice di qualità inferiore è inferiore, purché funzioni effettivamente.

Queste sono in definitiva decisioni aziendali, anche se è necessario assicurarsi che chiunque prenda la decisione sia a conoscenza della valutazione tecnica. Se devi spiegarlo alla direzione, spiega che è come acquistare un'auto usata. Alla fine spetta all'acquirente decidere se ne vale la pena, ma portarlo da un meccanico è una buona idea, quindi sai che non stai prendendo un limone.

Stai pagando, puoi richiedere quello che vuoi, comprese copie / rapporti di tutti i loro test unitari.

Potresti persino scrivere tu stesso i test o almeno le specifiche del test.

Sono d'accordo con la tua opinione in quanto è un'ottima misura della qualità del codice. Se un fornitore rifiutasse questa richiesta, suonerebbe un campanello d'allarme, perché non dovrebbero volerlo fare - hanno standard di qualità bassi e prendono scorciatoie?

Hai assolutamente ragione sul fatto che il tuo progetto necessita di unit test automatici, test continui, rapporti di copertura e ispezioni di unit test.

Tuttavia le cose impegnative non raggiungeranno i risultati desiderati come altri hanno dettagliato.

La tua sfida è spiegare e persuadere le persone - abilità molto più difficili!

Inizialmente avrei iniziato con la gestione, spiegando i pro e i contro dei test e il payoff lungo la strada. Si prega di fare attenzione a non comunicare l'emozione dietro dichiarazioni come "scrivo unit test PROPER" (maiuscole e minuscole). Non vuoi "gridare" le parole (come implica TUTTO MAIUSCOLO) per convincere e convincere le persone in modo che loro stesse possano scegliere la soluzione giusta.

Alla fine, se non riesci a introdurre queste metodologie e ad abbracciarle dove sei, in più se sei appassionato di loro come dici (il che è buono!), Farei una società diversa come ce ne sono molte che valorizzano queste cose e ti daremo il benvenuto a bordo. Assicurati solo di essere in prima linea su di loro nelle interviste in modo che sappiano dove si trovano le tue passioni e se sarai adatto.

Forzare i test automatizzati su qualcuno non otterrà i risultati desiderati come hanno sottolineato @Joachim Sauer e @Telastyn nei loro commenti. Per molte persone i test di unità automatizzati rappresentano un enorme cambiamento nel loro modo di pensare. Perché molte persone scrivono codice che funziona, ma non è molto testabile. Potrei scrivere una pagina Web ASP.NET in cui tutta la logica, l'interrogazione del database, le regole aziendali, gli oggetti, ecc. È nel codice dietro. La pagina funzionerà? Sì. È testabile utilizzando test di unità automatizzati? Assolutamente no. Se un fornitore non dispone di test di unità automatizzati, ci vorrà abbastanza sforzo per imparare a scrivere correttamente i test di unità e, come risultato dell'apprendimento, riscrivere o ricodificare il proprio codice per renderlo più facilmente testabile. È probabile che passeranno quel costo su di te.

Il fatto è che il fornitore ti offre un prodotto, che si tratti di un'applicazione .dll o di Windows, e ti aspetti che funzioni il 99% delle volte. Certo ci sono bug qua e là, ma per la maggior parte dovrebbe funzionare. Questa è un'aspettativa ragionevole, soprattutto se il fornitore desidera mantenere la propria attività. Se si tratta di una scatola nera, non importa come funzionino, potrebbero usare un'ondata umana di tester o una stanza piena di scimmie che premono casualmente chiavi. Finché funziona. Ma avrebbero bisogno di fornirti una sorta di altra documentazione su come usarlo.

Tuttavia, se ti fornissero il codice sorgente in modo da poterlo modificare, mi aspetterei dei test unitari. Non lavorerei con un'azienda che non fornisce unit test. In quale altro modo sapresti che una modifica apportata non fa il tutto?

I test unitari sono un'indicazione di come quel fornitore gestisce i rischi durante il ciclo di sviluppo. Coloro che utilizzano i test unitari valutano la riduzione del rischio e la qualità di tali test è un'indicazione di quanto rischio è stato gestito.

Detto questo, i test unitari non definiscono il livello di rischio che il progetto sta tentando di affrontare. Inoltre, non ha alcun ruolo nella riduzione del rischio introdotto da cattive pratiche di programmazione.

Pertanto, potresti avere un fornitore che ha in atto solide pratiche di collaudo ma continua a scrivere codice altamente rischioso mentre un altro fornitore che non effettua test zero ma scrive codice a basso rischio. Se i due fornitori offrono lo stesso prodotto, allora è meglio andare con il fornitore a basso rischio.

Ciò può essere misurato solo intervistando, tutorando e apprendendo le personalità e le abilità delle persone coinvolte con quel fornitore.

Ho trovato questo articolo sull'acquisto di software personalizzato abbastanza utile: http://blog.8thlight.com/paul-pagel/2012/06/20/entrepreneurs-guide-to-buying-software.html

La domanda numero uno che raccomandano di porre è se il fornitore scrive i test.

Concordare con altri che i test unitari richiesti porterebbero a test a fini di test; qualcosa che è molto contrario a quello che vuoi.

Nel processo di controllo dei fornitori; chiedi loro qual è il loro processo di sviluppo poiché i test sono solo una parte di quel processo.

Hanno un processo di compilazione automatizzato? Seguono un paradigma di gestione? Hanno tester adeguatamente formati e un team indipendente di controllo della qualità ? Che ne dici di standard di documentazione?

Questi ti aiuteranno a giudicare la qualità complessiva del loro processo e, a sua volta, la qualità di ciò che producono.

Mi sembra che l'inclusione di questo requisito avrebbe pochi vantaggi pratici, poiché sarebbe impossibile far rispettare.

È possibile richiedere il codice per i test effettivi o un rapporto su quali test effettivi sono stati eseguiti e passati. Se si tratta di un progetto proprietario, il fornitore probabilmente non vorrebbe fornirlo, dal momento che sarebbe altamente suggestivo dei dettagli del codice, e potrebbe essere pronto a fornire dettagli di implementazione di basso livello e dire come fare il loro lavori. Ad un certo punto, ci deve essere un po 'di fiducia.

In caso contrario, potrebbero anche farti saltare ma semplicemente selezionando la casella accanto a "esegue una suite di test unitari" per soddisfare il requisito scrivendo un singolo test che passa se la loro utility viene compilata ed eseguita o un analogo analogo sforzo.

Quindi, sebbene i test di unità automatizzati siano una pratica encomiabile, non credo sia pratico insistere su questo da fornitori esterni.

Come molte persone hanno sottolineato, forzare i distributori a scrivere test unitari (o meglio, una combinazione di test automatizzati di unità e integrazione) per adempiere a un contratto probabilmente non produrrà risultati di alta qualità. D'altro canto, concordo sul fatto che i test automatizzati sono di gran lunga il metodo migliore attualmente in uso per garantire la qualità del codice.

Penso che il codice scritto con i test unitari sia molto più facile da mantenere rispetto al codice che è stato scritto per primo e che è stato aggiunto successivamente ai test unitari. Forza la modularità e le dipendenze minime. I test di integrazione sono anche necessari per verificare la correttezza del codice, ma non hanno lo stesso impatto sulla qualità del codice come è scritto. In sostanza, i test di integrazione automatizzata potrebbero essere aggiunti dopo il fatto, ma i test unitari hanno il maggiore impatto se scritti con il codice originale.

Il mio consiglio per la tua situazione è cercare distributori che preferiscono scrivere codice con test unitari e sceglierli rispetto ai distributori che tendono a non scrivere codice con test unificati. Se la direzione pagherà per questo, inserire i test automatici nel contratto ma SOLO SE IL VENDER È UTILIZZATO PER SCRIVERE IL CODICE CON LE PROVE DELL'UNITÀ.

Consente di ottenere subito le priorità ...

Nel tuo ruolo di cliente, la tua preoccupazione principale non è il test unitario

Se stai usando fornitori che producono software per te, allora non dovresti preoccuparti se stanno usando una metodologia o un'altra. La tua posta in gioco è acquisire una sorta di soluzione che ti aiuterà a raggiungere i tuoi obiettivi. L'unica cosa di cui dovresti preoccuparti è che la soluzione sia accettabile o meno. Ecco perché abbiamo i test di accettazione in quanto è responsabilità dell'utente assicurarsi di ottenere ciò che si desidera. È nel momento cruciale dell'accettazione da parte del cliente che il denaro verrà trasferito dalle tasche della tua azienda nella tasca del fornitore.

Potresti richiedere unit test come requisito consegnabile ma ci sono diversi problemi ereditari con essi, il più grave è che non esiste un modo sicuro per determinare in anticipo le metriche:

• Qual è la quantità accettabile di test unitari?

Dovrebbero esserci 10 test? Che ne dici di 100 test? Che ne dici di 1000 test? In realtà, è abbastanza difficile determinare all'inizio di quanti test avrai bisogno. Il numero effettivo è davvero indeterminabile ... come il problema di arresto ... ma non stiamo risolvendo quel problema.

Volete solo un software con test unitari in modo da poter continuare lo sviluppo. I test unitari non dicono ancora cosa hai rotto, ma sono incredibilmente adatti a dirti quando il codice ha un bug di regressione.

• Qual è un livello accettabile di copertura del codice?

"100%, ovviamente!" penseresti. Sfortunatamente questa metrica è fuorviante; anche se avevi una copertura del codice del 100%, sei davvero sicuro che le cose funzionino come previsto? È possibile avere una copertura del 100% ma non farlo.

Quello che devi davvero fare è il test esplorativo, cioè trovare qualcuno che è veramente bravo a rompere le cose e lasciargli fare il test. Per trovare i bug che nessuno sviluppatore ha mai pensato.

Inoltre, il 100% è talvolta irraggiungibile con test unitari puri se si dispone di alcuni hack di prestazioni necessari e si utilizzano modelli di progettazione che sono difficili da testare (cercare "singleton" e "tdd" nel proprio motore di ricerca preferito e troverete alcuni esempi).

Volete che il software consegnato funzioni e il documento delle specifiche è la vostra unica garanzia che lo farà.

Avrai bisogno di un livello superiore di test

Il documento di specifica deve essere verificato in qualche modo. Ogni punto deve essere esaminato con i fornitori che hanno obiettivi chiari e criteri di accettazione. Un'organizzazione di QA ben funzionante (o un fantastico tester se hai un budget limitato e un ambito limitato) fornirebbe i casi di test per verificare questi criteri di accettazione. È inoltre necessario qualcuno per verificare tali criteri di accettazione.

Esistono diversi modi per verificare i tuoi obiettivi e se qualcuno mi dice che non puoi fissare obiettivi di qualità, prestazioni ed efficienza sani, li colpirò in testa con libri pesanti e pesanti rispettivamente sui test di esplorazione, prestazioni e usabilità. Può essere facile esagerare con gli obiettivi, ma la conoscenza e la comunicazione ti aiuteranno a stabilire obiettivi realistici.

Non sono un avvocato ma la maggior parte dei contratti di progetto (che è fondamentalmente la madre di tutte le specifiche per il progetto) che ho letto di solito hanno un criterio di rapporto di difetto che stabilisce su quanti bug ritenuti accettabili. I bug vengono generalmente determinati in base alla gravità, i bug che bloccano lo spettacolo rilevati dal QA hanno una bassa tolleranza mentre le imperfezioni minori hanno un'alta tolleranza. Nei progetti reali è difficile richiedere che il software debba presentare 0 difetti. Le scadenze di solito mettono fine a quella pratica. È in queste situazioni che devi iniziare a contrattare l'ambito.

La maggior parte dei software forniti che ho visto di solito non vengono forniti con test unitari. Si potrebbe sostenere che i fornitori dovrebbero essere abbastanza professionali da fornire questo, tuttavia il motivo principale per cui si desidera che vengano consegnati i test unitari è assicurarsi che non si ottengano bug di regressione e anche abilitare il refactoring. Nella vita reale, con progetti in tempi stretti, sia il fornitore che il cliente ridurranno il campo di applicazione e le unit test andrebbero di solito fuori dalla finestra e rimosse dall'elenco dei risultati richiesti.

È un po 'triste che un software open source di alto profilo venga consegnato con unit test ma uno sviluppatore di software professionale non può, giusto?

Quindi, quando cliente, mi occupo dei test unitari?

Direi che l' unica volta che ti interesserà veramente dei test unitari è se il software consegnabile è un componente autosufficiente che non viene eseguito come programma autonomo, per il quale il test più grossolano che puoi fare è un test unitario . Le librerie di classi sarebbero un tipo di prodotto che può essere consegnato insieme a unit test.

Come fai a sapere che i fornitori non stanno scrivendo test unitari.

Forse la direzione e il venditore hanno avuto una riunione e il venditore ha detto, il codice costa $ X e i test unitari costano $ Y. La gestione del pizzicotto ha detto che vogliamo solo il codice.

Il venditore ha deciso di scrivere comunque unit test (per qualità) e di non condividerli con te (per vantaggio competitivo).

Ora è necessario apportare alcune importanti modifiche al software. Dato che possiedi il codice, puoi farlo da solo o noleggiarlo in modo competitivo (non necessariamente al fornitore originale). Ma poiché non hai acquistato i test unitari, il fornitore originale sarà in grado di eseguire lavori di qualità comparabile a un prezzo più economico rispetto a qualsiasi concorrente.

Ci sono molti progetti che hanno molto successo, nonostante non utilizzino test unitari. Guarda il kernel di Linux, è un progetto gigantesco con una complessità ben al di là di ciò che potresti trovare in qualsiasi progetto normale, e funziona ancora. Quindi, se il risultato è un buon software, non dovresti preoccuparti di come lo hanno raggiunto.

No, non è necessario richiedere necessariamente unità di test complete e automatizzate. È più importante che ti forniscano documenti di strategia di test adeguati. Stiamo andando bene in questo modo.