Ti stai chiedendo quali sono i pro ei contro sul TDD / test delle unità automatizzate e stai cercando la visione della comunità se è accettabile per gli sviluppatori professionisti scrivere applicazioni senza sostenere i test unitari?
Ti stai chiedendo quali sono i pro ei contro sul TDD / test delle unità automatizzate e stai cercando la visione della comunità se è accettabile per gli sviluppatori professionisti scrivere applicazioni senza sostenere i test unitari?
Per testare cosa?
Se si parla di copertura del codice al 100%, è estremamente raro, non utile e spesso impossibile. Allo stesso modo, testare il codice relativo a CRUD è una perdita di tempo, e sarebbe molto poco professionale passare ore a scrivere codice che non è necessario invece di fare qualcosa di veramente utile.
Ora, come sviluppatore, devi sapere come scrivere test unitari e dove ti servono.
C'è un malinteso comune che i unit test siano per testare "unità" .
Test unitari, allo stesso modo tutti gli altri test, funzionalità di test . Semplicemente non è possibile testare nient'altro.
Tuttavia, la funzionalità di un sistema complesso spesso non può essere testata in modo efficace.
Ad esempio, un utente preme un pulsante "Elimina" e non succede nulla. Perché? Un errore può essere all'interno di un database, una connessione può essere interrotta, una logica di base può funzionare male, o anche un'operazione può avere successo ma l'interfaccia non si aggiorna correttamente. Ogni livello può contenere molte funzioni che si chiamano l'un l'altro, e non è sempre chiaro dove si trova l'errore.
I test unitari si basano su un paradigma di separazione dei componenti e li testano individualmente.
Ancora una volta, non garantisce che tutto il sistema funzioni, ma semplifica i test.
TDD non è un requisito da solo. Semplifica la codifica costringendo uno sviluppatore a rispondere per prima cosa, "che cosa sto realmente andando a codificare?".
Molti pensano che non scrivendo test, risparmiano il loro tempo. Sbagliato. Pensando strategicamente, il costo di un errore aumenta in modo esponenziale con il tempo dall'apparizione fino al rilevamento.
Supponiamo di aver commesso un errore nel codice e di individuarlo e correggerlo lo stesso giorno. Il costo è $ X .
Supponiamo che l'errore non venga rilevato e passi alla compilazione interna settimanale. Fortunatamente, il QA lo ha rilevato, ha sollevato un bug nel bug tracker, il problema era un argomento di discussione di 5 minuti su un incontro di 5 persone, ecc. Infine, lo aggiustate. Il costo è la somma della manodopera spesa da tutti, e potrebbe essere $ 3 * X in questo caso.
Cosa succede se l'errore è andato in beta testing e coinvolge più persone? Diciamo, $ 10 * X .
Se rimane inosservato per un lungo periodo, è andato a 1.000 clienti (si spera, non a un milione!), 10 di loro l'hanno rilevato, hanno sollevato una discussione con il personale di supporto, alcuni potrebbero chiamare il tuo capo, i tuoi compagni di squadra tentare di riprodurlo ecc. Infine, il bug ritorna da te e tu lo aggiusti. Quanto, in totale? Bene più di $ 50 * X .
Come vedi, un bug prima o poi tornerà a te (o al tuo collega). L'unica differenza è quando succede e quanto costerebbe.
I test unitari accorciano il ciclo di vita dei bug e quindi riducono i costi.
Posso vedere una sola scusa per non scrivere test. Se stai scrivendo un prototipo, ad es. qualcosa che non andrà mai alle altre persone. O forse stai scrivendo qualcosa per un singolo uso.
Certo, è accettabile non scrivere test unitari per piccole utility helper interne, o strumenti di test, o scenari in cui business realmente ha bisogno di cose diverse dalla qualità e tu come lo sviluppatore professionista trova che è possibile ottenere il software fatto e lavorare altrettanto velocemente senza.
Secondo la mia esperienza, il 95% degli errori che possono essere rilevati dai test unitari provengono da chiamate al livello dati, specialmente dopo le modifiche alla progettazione del database. Se stai usando un database, basta mettere un test su ogni metodo che usi per accedervi. I test non hanno nemmeno bisogno di essere elaborati, solo controlli di sanità.
In risposta alla tua domanda: se accedi a un database e sei uno sviluppatore professionista, dovresti usare i test unitari. Altrimenti, dipende.
Dipende davvero da come verrà utilizzata l'applicazione. È un'applicazione mission-critical? O è una semplice applicazione di verifica utilizzata solo internamente dagli sviluppatori? Quando si lavora sulle applicazioni principali della propria azienda, dovrebbero essere necessari tutti i test unitari necessari per garantire che le decisioni aziendali siano coperte. A seconda della tua azienda, quelle sono le applicazioni che i clienti vedono e i bug potrebbero costare. Se eseguito correttamente, i test unitari possono essere di grande aiuto per garantire che le applicazioni funzionino quando vengono implementate. Ma non è una cura tutta e dovrebbero ancora essere fatti test umani. Semplici applicazioni interne (o secondarie) non hanno bisogno di test unitari, ma dovrebbero comunque essere scritti bene.
TDD non riguarda solo la scrittura dei test. Si tratta di assicurarsi che il tuo codice sia facilmente verificabile. E il più delle volte il codice facilmente verificabile è anche più facile da leggere / debug / mantenere. Il più delle volte il codice facilmente verificabile segue anche schemi e principi OO come SOLID. Direi che come sviluppatore professionista il tuo codice dovrebbe sempre essere scritto in questo modo.
Sicuramente non vuoi "nessun test". Se scrivi dei test unitari, hai almeno una certa sicurezza che il tuo codice corrisponda ai tuoi test (anche se dovresti assicurarti che i tuoi test corrispondano alle tue specifiche).
Non hai finito se tutto quello che hai sono test unitari, però. Probabilmente hai ancora bisogno di fare test di integrazione e test end-to-end (e nel tempo accumulare casi di test per ottenere regressioni di bug).
Ho intenzione di uscire su un arto qui e dire che è per lo più soggettivo e dipende dai tuoi obiettivi. tl; dnr: E 'bello da fare, ma essere dogmatici causerà più problemi.
I test TDD / Unit miglioreranno la stabilità del tuo codice. Rendono più facile apportare modifiche senza conoscere bene la base di codice, ti permettono di eseguire il refactoring più velocemente, ti permettono di essere sicuro che non stai facendo qualcosa di stupido. I test unitari possono anche essere una perdita di tempo. Tempo che potrebbe essere impiegato per scrivere codice. Può anche farti prendere in giro pensando che il tuo codice funzioni quando non lo fai se li segui ciecamente.
Se lavori per una società che supporta le best practice e ti dà il tempo di implementarle e vuoi un'applicazione che durerà, allora è davvero meglio per tutti usare e mettere in pratica i test unitari e le revisioni del codice. Avere una squadra di QA può essere un sostituto accettabile se gli sviluppatori non la abusano. Se stai scrivendo un prototipo (anche uno di produzione) potrebbe essere più veloce il solo fare test del fumo.
Se stai lavorando su qualcosa in cui un pasticcio non sarà la fine del mondo, probabilmente meno copertura andrà bene. Transazioni finanziarie? Molte. Se hai un team di forti sviluppatori che conoscono il codebase, lavorano bene insieme e non c'è un giro d'affari, allora probabilmente hai bisogno di meno copertura. Ecc.
Quindi probabilmente sarà una funzione di
Ci sono molte situazioni in cui non scrivere test unitari sarebbe accettabile. TDD è 'in' adesso, ma non è un proiettile d'argento.
È professionale scrivere test di unità manutenibili che ti faranno risparmiare tempo e lacrime
C'è un misconception that Unit test finds bugs . Beh, questo è semplicemente NON vero per tutti i casi. Il test unitario non riguarda la ricerca di bug o la rilevazione di regressioni. È per definizione, examine each unit of your code separately . Ma quando la tua applicazione funziona per davvero, tutte queste unità devono lavorare insieme, e il tutto è più complesso e sottile della somma delle sue parti testate indipendentemente.
Pertanto, l'obiettivo del test delle unità (all'interno del processo TDD) riguarda la progettazione di componenti software in modo robusto.
Modifica: c'è un'eccezione in cui i test unitari rilevano effettivamente i bug. È quando si esegue il refactoring o si ristruttura il codice di un'unità, ma senza significato cambiare il suo comportamento . In questo caso, i test unitari possono spesso dirti se il comportamento dell'unità è cambiato.
As a professional developer, is it acceptable to not write unit tests?
No.
Senza dubbio - Questa dovrebbe essere una delle prime lezioni che impara di più. devi sviluppare test unitari per dimostrare che il tuo codice funziona prima dici a QA che il tuo codice è pronto per essere testato. Un fallimento nel fare ciò aumenterebbe i costi del progetto e abbasserebbe il morale della squadra.
How thorough should these unit tests be?
Ecco la cartina di tornasole: se QA scopre un bug nel tuo codice, ti sentirai a tuo agio usando i tuoi test di unità per dimostrare la dovuta diligenza al tuo capo?
Se la tua risposta è "No", allora dovresti creare un test unitario migliore (o test).
Se la tua risposta è "Sì", il tuo codice è pronto per la verifica.
As a professional developer, is it acceptable to not write automated unit tests?
Sì.
Soprattutto se il tempo e lo sforzo impiegati per scrivere test unitari automatizzati superano i benefici ottenuti dal test. Questo include, ma non è limitato a, codice UI che può essere difficile da deridere.
Enfasi: io sono non che dice che è impossibile scrivere test unitari automatizzati per il codice UI. Sto solo dicendo che, secondo la mia esperienza, a volte è difficile scrivere test unitari automatizzati per alcuni codice UI.
Leggi altre domande sui tag testing unit-testing