Se i test unitari sono così eccezionali, perché non lo fanno più aziende? [chiuso]

La prima vera azienda di software in cui ho lavorato era incentrata sull'unità di test (NUnit). Non so se all'epoca eravamo dei veri pignoli per questo - non ho idea di come fosse la copertura del nostro codice e stavo scrivendo la maggior parte degli unit test. Da allora mi sono imbattuto in alcune aziende che eseguono molti test, ma è un test su sedia: si basa sulla presenza di una persona, ha una bassa ripetibilità e poche possibilità di rilevare bug. L'altro atteggiamento è: era qualcosa con cui volevano andare avanti "in futuro"; in pratica quando i soldi cadono dal cielo.

Mi mancano i test unitari: semplifica la vita. Ma sto scoprendo che quando cerco un nuovo lavoro, i test unitari sono qualcosa con cui le aziende vorrebbero "andare avanti" in futuro o qualcosa che non fanno affatto (uhh, è in circolazione da un po ' adesso!). Direi che il 60-75% delle richieste di lavoro che ho esaminato negli ultimi 2 anni non ha elencato affatto i test di unità. Posso solo pensare a uno o due che avevano esperienza di unit test come requisito (per una posizione di sviluppatore di medio livello).

Quindi la domanda è: cosa manca ? Penso che renda le persone più produttive, ma solo dopo aver speso una buona quantità di tempo a farlo effettivamente. Non ci sono buoni studi sui risparmi sui costi dei test unitari? È il tipo di azienda che sto guardando?

Modifica: anche se il titolo è un po 'diabolico, mi considero un sostenitore dei test di unità.

Nella mia esperienza, ci sono un paio di fattori coinvolti in questo:

1. La direzione non capisce veramente cosa sia veramente il test unitario o perché abbia un valore intrinseco reale per loro.
2. La direzione tende a essere più interessata alla consegna rapida dei prodotti e (erroneamente) considera i test unitari controproducenti per tale obiettivo.
3. C'è un'errata percezione che il test appartenga esclusivamente al pervertito del controllo qualità. Gli sviluppatori sono programmatori e non possono scrivere test.
4. C'è una percezione errata comune che la direzione debba spendere soldi per eseguire correttamente i test unitari, nonostante il fatto che gli strumenti siano disponibili gratuitamente. (C'è, ovviamente, lo sviluppatore accelera il tempo per prendere in considerazione, ma non è davvero proibitivo.)
5. La risposta di Will completerà questa risposta: è molto difficile determinare il valore del codice di prova (modifica jcollum)

Naturalmente, ci sono altri fattori, ma questi sono solo quelli in cui mi sono imbattuto finora.

1) È difficile
2) Ci vuole tempo
3) È molto difficile determinare il valore del codice di prova

Il punto 3 è appiccicoso. Buoni test unitari riducono i bug. Ma anche un buon codice di produzione. Come si determina quanti bug non esistono a causa dei test unitari? Non puoi misurare ciò che non esiste. Puoi indicare gli studi, ma non si adattano bene al foglio di calcolo del tuo manager aziendale.

È facile dare tutta la colpa alla "gestione". Ma la direzione ti sta davvero dicendo di non eseguire alcun test di unità?

La direzione in generale non ti dice (e probabilmente non dovrebbe) come svolgere il tuo lavoro, che si tratti di modularizzazione, tipi di dati astratti, modelli di progettazione o test di unità. Questi sono strumenti di lavoro che un ingegnere del software competente e di successo applica, ma un ingegnere povero no.

Penso che la vera risposta alla tua domanda sia: il test unitario è davvero difficile e gli studenti di informatica non sono addestrati per questo.

È facile quando scrivi la tua classe di stringhe. Quando provi un prodotto reale, ti imbatti in sfide di cui nessuno ti ha parlato nelle diapositive powerpoint:

• Interazione dell'utente. La metà della tua applicazione è la logica dell'interfaccia utente. Come lo provi in ​​modo automatico, che non si interrompe se muovi un pulsante?
• Interazione con API e framework esterni. Se stai scrivendo un driver del kernel di Windows, come lo fai unit test? Scrivi stub per ogni IRP e funzione del kernel che usi, creando effettivamente una simulazione del kernel del sistema operativo?
• Le comunicazioni di rete sono la cosa del 21 ° secolo. Come si coordina uno unit test costituito da più componenti distribuiti?
• Come scegli i buoni casi di test? Vedo comunemente persone che provano l'approccio "fai cose casuali in un ciclo di 1000 iterazioni e vedi se si interrompe". Quando si esegue questa operazione, lo sforzo è maggiore dei ritorni, vengono persi bug importanti e il test di unità viene abbandonato.
• Come verifichi che i requisiti di prestazione siano soddisfatti?
• La conoscenza dei modelli nei test è scarsa: stub, risposte preconfezionate, test di regressione sono concetti che la maggior parte delle persone non conosce. Quanti nel tuo posto di lavoro leggono effettivamente un libro sui test unitari?

L'unica cosa di cui possiamo incolpare la direzione è che le specifiche dei requisiti raramente contengono requisiti sul livello di qualità del prodotto.

La prossima volta che il tuo capo ti chiede di fare una stima del tempo, includi il tempo per scrivere un test unitario e guarda cosa succede.

La maggior parte dei test non verifica nulla.
Scrivi una funzione fileopen () e un unittest che fallisce se il file non esiste e riesce se il file esiste. Grande! Ora hai controllato se funziona con il nome del file in cinese BIG5? su una condivisione NFS? su vista con il file su una chiave USB e UAC acceso?

Il problema è che gli unit test sono scritti dallo stesso programmatore che ha scritto la funzione, con lo stesso insieme di presupposti e con lo stesso livello di abilità. Per funzionare davvero i test devono essere scritti da qualcun altro, solo per le specifiche pubblicate senza che questi vedano il codice. - Nella maggior parte delle aziende il solo fatto di ricevere specifiche scritte sarebbe una svolta!

I test unitari verificano la presenza di errori nel codice delle singole funzioni. Possono funzionare per livelli di accesso ai dati, librerie matematiche, ecc. Dove gli input / output sono ben noti e la struttura interna è complessa, ma per molti casi sono solo una perdita di tempo.
Non riescono quando gli errori sono dovuti alle interazioni tra diverse parti di codice o con il sistema operativo e l'utente. Problemi come le impostazioni DPI alto / basso che rovinano una finestra di dialogo o l'impostazione di una lingua straniera che scambia un "." e "," di solito non vengono trovati.

Sono stati condotti studi sul ROI dei test unitari - vedere questa domanda .

Ho trovato molti sviluppatori che non sono interessati ai test di unità. Sembra sempre che ci sia un sacco di lavoro con poco guadagno quando inizi. Nessuno vuole iscriversi per un lavoro extra e quindi resistono. Una volta che le persone iniziano, di solito lo seguono con entusiasmo, ma farlo iniziare può essere difficile.

A parte il problema dell'adozione del test unitario, il test unitario non è sempre utile, anche se in generale penso che lo sia, se applicato correttamente. Non c'è niente di speciale nei test unitari che li eviti di essere vulnerabili a una cattiva costruzione.

I test unitari hanno costi (creazione, manutenzione e funzionamento) e sono utili solo se forniscono vantaggi maggiori rispetto a tali costi. La creazione di test è un'abilità come le altre, richiede esperienza e conoscenza specifiche per il successo. Senza una sufficiente esperienza è molto facile, anche per sviluppatori altrimenti esperti, creare unit test di bassa qualità, di basso valore e / o ad alto costo che non sono utili. Soprattutto considerando quanto possa essere difficile giudicare il valore di uno unit test.

Inoltre, il test unitario è solo un modo per migliorare la qualità del codice, ma non è l'unico modo. In alcune circostanze e con alcuni team potrebbe non essere il modo più efficace per aumentare la qualità del software.

Tieni presente che dedicare molto impegno ai test di unità non è una garanzia di software di qualità. Inoltre, è possibile produrre software della massima qualità senza alcun test di unità.

Ebbene, la mia azienda non è andata con TDD o Unit Testing. Ad essere onesti, non siamo sicuri di come farlo. Ovviamente possiamo farlo per funzioni stupide come CapitalizeString (), ecc., Ma non sappiamo come farlo per sistemi altamente complessi con oggetti complicati. Inoltre, la maggior parte delle persone intervistate ha zero esperienza o esperienza limitata. Sembra che Unit Testing sia grande dalla folla SO, ma non particolarmente grande nel pool di lavoro disponibile.

TDD è un argomento separato. Siamo moralmente contrari al TDD. Non siamo programmatori di cowboy, ma crediamo che ostacoli la creatività e la flessibilità in un progetto. Inoltre, avere il programmatore che ha scritto la funzione di unit test non ha senso. Quando faccio qualcosa, codifico per tutti i casi limite a cui riesco a pensare. Quello di cui ho bisogno è un altro cervello per cercare cose che potrei aver perso. Non l'abbiamo. Le squadre sono piccole e autonome.

Insomma, non crediamo nel TDD, ma vorremmo Unit Test. Semplicemente non abbiamo l'esperienza per farlo e non riusciamo a trovarlo facilmente.

Ci sono molte aziende là fuori che non fanno nulla sulla falsariga delle migliori pratiche. Nessuna revisione del codice, nessun test di unità, nessun piano di test, niente di niente, solo dal sedile dei loro pantaloni.

Cogli questa opportunità per convincerli a utilizzare una piattaforma di integrazione continua e sviluppare unit test! Un modo semplice per impressionare i poteri forti e aumentare la qualità e la stabilità del tuo codice allo stesso tempo

Modifica: Per quanto riguarda la ragione, penso che semplicemente non siano a conoscenza degli strumenti attuali che rendono i test CI e unità straordinariamente facili.

Da quello che ho visto, molte aziende hanno basi di codice enormi e altamente accoppiate che non sono praticamente testabili. Inoltre non hanno requisiti testabili decenti, quindi i test unitari verrebbero testati rispetto ai requisiti de facto "come costruiti".

Non credo che la pigrizia sia la causa principale di un cattivo test unitario. Per la mia azienda, i vincoli di tempo e l'atteggiamento "basta farlo" sono i maggiori deterrenti per fare test unitari. Inoltre, i luoghi in cui i nostri sistemi falliscono tendono ad essere più a livello di integrazione (servizi, accessi a database, query complesse che richiedono dati specifici per il test), non a "livello di unità". Queste cose sono solo più difficili da testare e se hai a malapena abbastanza tempo per completare la funzione, probabilmente non avrai tempo per eseguire test utili allo stesso tempo.

I test unitari dovrebbero essere solo una parte naturale del flusso di lavoro di sviluppo del codice, proprio come lo è il compilatore.

Tuttavia, ciò richiede di istruire la direzione sui vantaggi del test unitario. Tuttavia, gli sviluppatori junior hanno probabilità relativamente basse di avere tale influenza. Pertanto, se un'azienda è un sostenitore dello unit test dipende dal fatto che abbia uno sviluppatore senior o un architetto che è un sostenitore dello unit test.

Credo che questa sia la risposta alla tua domanda "cosa manca e perché non ci sono più aziende che eseguono test unitari" . :-)

Probabilmente è una combinazione di un paio di cose che hai già menzionato. È difficile misurare i risparmi sui costi di TDD. Se vuoi esternalizzare il tuo IT, puoi mostrare quanto paghi all'anno per i ragazzi che hai nel personale rispetto al costo per l'appalto; è molto concreto. Come si dice: "Oh, questo test ha rilevato un bug che mi avrebbe richiesto 4 ore per il debug e la correzione ..."?

Il motivo per cui alcuni posti non lo usano è semplicemente perché richiede molto lavoro sia per iniziare che per continuare. Il fatto che la scrittura di unit test richieda tanto tempo quanto la scrittura della funzionalità effettiva, ad alcuni manager sembra che tu stia dimezzando la produttività dello sviluppatore.

Inoltre, costruisci il team (o qualcuno) ha bisogno di mettere in atto l'infrastruttura e mantenerla.

E come dice Alan , molti posti semplicemente non usano le migliori pratiche, vogliono solo vedere qualcosa di tangibile.

Penso che il programmatore debba iniziare a farlo. Alcuni semplici test con cui iniziare sono facili da giustificare come parte dello sviluppo.

Qualcosa come uno unit test è quasi sempre necessario per ottenere un rapido debug. Spiega solo quanto è più veloce avviare il test piuttosto che organizzare l'input corretto, impostare un punto di interruzione del debugger, avviare l'applicazione, ecc.

Documenta il test nel tuo codice. Basta inserire un commento che spieghi dove si trova il test e come eseguirlo. I futuri programmatori lo vedranno e si spera che i test si diffondano!

Il test unitario è uno di quei termini da scatola nera che la maggior parte delle persone ha sentito, ma non sa cosa costituisca esattamente uno unit test, da dove iniziare, come scriverli, come eseguire effettivamente i test, cosa esattamente dovrebbero testare, ecc. ecc. ecc.

In molti casi, è più facile per lo sviluppatore incerto liquidarli semplicemente come non necessari o come una ciliegina che serve solo agli "sviluppatori di livello aziendale".

Sono un grande fan degli unit test e sono anche un partner in un'azienda che realizza progetti di sviluppo di contratti per vari tipi di clienti. Tra un mese toccheremo 3-4 diversi progetti di varie dimensioni.

Se un progetto sembra essere unico, non investirò molto nei test unitari perché quel test unitario non paga per la mia attività. Su questi tipi di progetti ho intenzione di testare unità di cose con cui non sono sicuro / non ho familiarità o che potrebbero cambiare frequentemente (come un parser per un'origine dati che non controllo).

Considerando che se sto costruendo qualcosa che so avrà una lunga durata, è un lavoro più ampio, su cui lavorerò attraverso più iterazioni, o avrà un grande impatto sui miei clienti se si verifica un errore , Investirò in più unit test. Anche in questo caso la priorità dei test ruota attorno al codice incerto / non familiare / che cambia.

Penso che i test unitari dovrebbero ruotare attorno alla complessità di un compito, così come se ripagheranno. Non ha senso scrivere codice extra che non verrà utilizzato.

Nella mia esperienza dipende davvero dal software che stai scrivendo. Ho scoperto che è estremamente difficile scrivere unit test per un'interfaccia utente. Uso i test unitari solo per le parti del sistema che hanno un ingresso / uscita definito.

Mi mancano i test unitari: semplifica la vita.

Questo non è , in realtà, un motivo sufficiente per un'azienda per adottare i test di unità.

Una ragione sufficiente potrebbe essere "più economica" (e / o, "migliore"): che non è così facile da provare sui test unitari.

L'unica buona ragione potrebbe essere "scrivere unit test è il miglior uso del tempo degli sviluppatori", che è davvero difficile da provare IMO: e potrebbe essere vero in alcuni punti, per alcuni software, con alcuni sviluppatori, e non vero altrove.

Ci sono molti sviluppatori che non pensano al mondo dei test unitari: inclusi alcuni che pensano che altre forme di test (es. Integrazione automatizzata / test funzionali) possano essere più economiche e preziose, ad esempio Am I the only dev che non lo fa ' ti piacciono i test unitari?

Ovviamente, nel mondo ideale, non puoi discutere contro avere uno unit test.

Tuttavia, se scrivi uno unit test dipende da una serie di cose:

• Come verrà utilizzato il software. Se scrivessi software solo per te stesso, scriveresti unit test? Probabilmente no. Se stavi scrivendo software preconfezionato da vendere in commercio, probabilmente sì.

• Quante persone mantengono il codice ... se sei solo tu, allora potresti conoscerlo abbastanza bene da essere abbastanza sicuro dopo aver apportato una modifica che una rapida lettura del codice è sufficiente per assicurarti che nulla sia rotto. Se altre persone che non hanno originariamente scritto il codice devono ora mantenerlo, uno unit test aiuterà a dare loro la certezza che quando aggiornano il codice per correggere un grosso (che ovviamente non è stato catturato nello unit test!) Non hanno rotto nulla .

• complessità del codice: solo codice di test che necessita di un test. Un metodo di assegnazione di una variabile di una riga non necessita di test. Un metodo a 50 righe con più percorsi di esecuzione probabilmente lo fa.

• Pratiche considerazioni commerciali commerciali: il fatto è che la scrittura di unit test richiede più tempo che non farlo. Se stai scrivendo un prototipo di software, che ha un futuro commerciale incerto, allora c'è una ricompensa da avere tra avere un codice rapidamente, ora, che funziona abbastanza bene rispetto ad avere un codice testato in 2 settimane che funziona meglio. A volte vale la pena scoprire rapidamente (appetito del consumatore) se il software avrà uno scaffale breve e passerà al progetto successivo.

e come altri hanno sottolineato, un test è valido quanto la persona che lo ha scritto.

Il motivo principale è che molti sviluppatori e responsabili dello sviluppo non hanno la più pallida idea dell'esistenza di unit test o di come usarli.

La seconda ragione è che gli unit test possono essere utilizzati (in modo sensato) solo con codice che già soddisfa alcuni standard di qualità. È probabile che alcuni codebase esistenti non rientrino in quella categoria.

La terza ragione è la pigrizia e / o l'economicità.

Perché gli unit test sono utili solo se scrivi codice testabile. E scrivere codice verificabile è difficile. E le persone sono pigre e / o economiche.

EDIT: sfumato "pigro" come "pigro e / o economico"; alcune rare volte, le persone hanno effettivamente l'abilità, la capacità e la volontà di scrivere test, ma hanno qualcos'altro da fare che influisce più direttamente sul risultato finale.

Penso che parte del problema sia che gli sviluppatori si aspettano che gli uomini d'affari abbiano lo stesso insieme di valori e che si preoccupino davvero della risposta a "dovremmo effettuare un test unitario o no?". Non otteniamo l'approvazione anticipata dall'azienda per utilizzare un linguaggio di alto livello piuttosto che un linguaggio assembly: di solito è solo il modo sensato per portare a termine il lavoro.

Il punto è che siamo gli unici qualificati per effettuare la chiamata (il che non vuol dire che tutti noi abbiamo la stessa conoscenza sull'argomento). Inoltre, anche se il tuo team, per una questione di politica, non esegue test di unità (o nomina-il-tuo-metodo-del-giorno) generalmente non significa che non puoi farlo.

La verità è che non possiamo davvero dimostrare il ROI sulla maggior parte delle cose che facciamo con una granularità troppo fine. Perché lo unit test è tenuto a questo standard di prova irragionevole / non tipico è al di là di me ...

Le persone sono pigre e adottano il cambiamento solo quando sono costrette a farlo.

I miei 2 centesimi:

• Richiede istruzione e disciplina, ma i neolaureati arrivano già con le conoscenze adeguate.
• Il sovraccarico dei test può essere ridotto con strumenti migliori e questo sta accadendo anche (refactoring ecc.)

Quindi è solo questione di tempo.

C'è il dibattito Martin-Coplien in cui Bob Martin afferma che:

"al giorno d'oggi è irresponsabile per uno sviluppatore fornire una riga di codice che non ha eseguito in uno unit test."

[ http://www.infoq.com/interviews/coplien-martin-tdd]

Se vuoi vendere a tutti in fase di test, procedi come segue:

1. Scrivi una serie di test.
2. Avvisa gli altri sviluppatori che modificano il codice e non superano i test.
3. Correggeranno il loro codice.
4. Ora puoi rilasciare senza quei particolari bug.

Anche un manager potrebbe capirlo.

Le aziende non eseguono test di unità, per lo stesso motivo per cui molti siti Web sono scritti male: ignoranza e persone che si attengono alle vecchie abitudini. Nella mia azienda, da quando abbiamo iniziato i test unitari (con Nunit e Typemock ), raggiungiamo una maggiore copertura del codice e rilasciamo il software in un tempo più breve sul mercato.

Come la maggior parte delle buone idee, l'adozione ha più a che fare con la dipendenza dal percorso organizzativo che con la qualità dell'idea.

Nella maggior parte delle aziende che hanno spedito prodotti, è stata creata una sostanziale divisione QA con un responsabile QA di livello senior. Il test è il feudo del team QA.

È improbabile che il team di QA scriva il codice di unit test perché la società in genere non fornisce al team di QA i suoi programmatori pesanti.

Il team di programmazione è riluttante a scrivere codice di test perché crea un conflitto con il team di QA.

Ho riscontrato maggiore interesse e adozione dello Unit Testing in gruppi in cui il controllo qualità non è stato scorporato in una funzione lavorativa separata

Semplicemente costa denaro per scrivere e aggiornare gli unit test. La maggior parte delle aziende software precedenti non ha test unitari e costerà troppo per scrivere. Quindi non lo fanno e aggiunge tempo al processo di sviluppo, quindi non lo aggiungono a nuove funzionalità.

La maggior parte delle aziende è inutile. Non quello per cui tu (o io) lavoriamo, ovviamente.