Come sviluppatore professionista, è accettabile non scrivere unit test? [chiuso]

Ti chiedi solo i pro e i contro su TDD / test di unità automatizzati e cerchi l'opinione della comunità se è accettabile per gli sviluppatori professionisti scrivere applicazioni senza supportare i test di unità?

Per provare cosa?

Se stai parlando del 100% di copertura del codice, è estremamente raro, non utile e spesso impossibile. Allo stesso modo, testare il codice relativo a CRUD è una perdita di tempo e sarebbe altamente poco professionale passare ore a scrivere codice che non ti serve invece di fare qualcosa di veramente utile.

Ora, come sviluppatore, devi sapere come scrivere test unitari e dove sono necessari.

Teoria

C'è un malinteso comune sul fatto che i test unitari siano per testare "unità" .
Test unitari, come tutti gli altri test, funzionalità di test . Non c'è nient'altro che possa essere testato.

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é? Potrebbe esserci un errore all'interno di un database, una connessione potrebbe essere interrotta, una logica di base potrebbe non funzionare correttamente o anche un'operazione potrebbe avere esito positivo ma l'interfaccia non si è aggiornata 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 componenti separati e li testano individualmente.

Ancora una volta, non garantisce che l'intero sistema funzioni, ma semplifica i test.

TDD non è un requisito in sé. Semplifica la codifica costringendo uno sviluppatore a rispondere per primo, "che cosa sto davvero per programmare?".

Costi

Molti pensano che non scrivendo test, risparmino tempo. Sbagliato. Pensando strategicamente, il costo di un errore aumenta esponenzialmente con il passare del tempo dall'apparizione fino al rilevamento.

Supponi di aver commesso un errore nel codice, di individuarlo e risolverlo lo stesso giorno. Il costo è di $ X .
Supponiamo che l'errore rimanga inosservato e passi alla build interna settimanale. Fortunatamente, il QA lo ha rilevato, ha sollevato un bug nel bug tracker, il problema è stato oggetto di una discussione di 5 minuti su una riunione di 5 persone, ecc. Infine, lo hai risolto. Il costo è la somma della manodopera spesa da tutti, e in questo caso potrebbe essere $ 3 * X.
Cosa succede se l'errore è andato al beta test e coinvolge più persone? Diciamo di Let, $ 10 * X .
Se rimane inosservato per molto tempo, è andato a 1.000 clienti (si spera, non a un milione!), 10 di loro lo hanno rilevato, hanno sollevato una discussione con il personale di supporto, alcuni potrebbero chiamare il tuo capo, i tuoi compagni di squadra tentano di riprodurlo , ecc. ecc. Infine, il bug ritorna da te e lo risolvi. Quanto, in totale? Ben più di $ 50 * X .

Come vedi, un bug prima o poi tornerà da te (o dal tuo collega). L'unica differenza è quando succede e quanto costerebbe.
I test unitari riducono il ciclo di vita dei bug e quindi riducono i costi.

Professionisti

• I test unitari consentono allo sviluppatore di codificare meglio . Così semplice.
• Ti permettono di risparmiare tempo;
• Riducono i costi;
• I test unitari vivono insieme al codice che testano. Ad ogni richiesta di modifica (che accade sempre), i test si adatteranno.

di Con

Vedo una sola scusa per non scrivere test. Se stai scrivendo un prototipo, ad esempio qualcosa che non andrà mai alle altre persone. O forse stai scrivendo qualcosa per un singolo uso.

Certo, è accettabile non scrivere unit test per piccole utility interne di supporto, o strumenti di test o scenari in cui il business ha davvero bisogno di cose diverse dalla qualità e tu come sviluppatore professionista scopri che puoi ottenere il software fatto e funzionare altrettanto rapidamente senza.

Nella mia esperienza, il 95% degli errori che possono essere rilevati dai test unitari provengono da chiamate al livello dati, in particolare dopo modifiche alla progettazione del database. Se stai usando un database, metti un test su ogni metodo che usi per accedervi. I test non devono nemmeno essere elaborati, solo controlli di integrità.

In risposta alla tua domanda: se accedi a un database e sei uno sviluppatore professionista, dovresti utilizzare i test unitari. Altrimenti dipende.

Dipende molto 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 per la propria azienda, devono essere eseguiti tutti i test unitari necessari per garantire la copertura delle decisioni aziendali. A seconda della tua azienda, queste sono le applicazioni che i clienti vedono e i bug potrebbero costare i soldi. Se fatto bene, i test unitari possono essere di grande aiuto per garantire che le applicazioni funzionino una volta distribuite. Ma non è una cura per tutti e dovrebbero ancora essere eseguiti test umani. Le applicazioni interne (o accessorie) semplici non richiedono test unitari, ma devono comunque essere scritte bene.

TDD non si tratta solo di scrivere prima i test. Si tratta di assicurarsi che il codice sia facilmente testabile. E molto spesso il codice facilmente testabile è anche più facile da leggere / eseguire il debug / mantenere. Il codice più spesso che non facilmente testabile 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 test unitari, hai almeno la certezza che il tuo codice corrisponde ai tuoi test (anche se dovresti assicurarti che i test corrispondano alle tue specifiche).

Non hai finito se tutto ciò che hai è unit test, però. Probabilmente è ancora necessario eseguire test di integrazione e test end-to-end (e nel tempo accumulare casi di test per rilevare le 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: è bello da fare, ma essere dogmatici al riguardo porterà a ulteriori problemi.

I test TDD / unità miglioreranno la stabilità del codice. Semplificano le modifiche senza conoscere molto bene la base di codice, ti consentono di eseguire il refactoring più velocemente, ti consentono di essere sicuro di non fare qualcosa di stupido. I test unitari possono anche essere una perdita di tempo. Tempo che potrebbe essere trascorso a scrivere codice. Può anche farti ingannare nel pensare che il tuo codice funzioni quando non lo fa se li segui alla cieca.

Se lavori per un'azienda che supporta le migliori pratiche e ti dà il tempo di implementarle e desideri un'applicazione che duri, allora è davvero meglio per tutti usare e mettere in pratica i test unitari e le revisioni del codice. Avere un team di controllo qualità può essere un sostituto accettabile se gli sviluppatori non lo abusano. Se stai scrivendo un prototipo (anche uno di produzione) potrebbe essere più veloce il solo test del fumo.

Se stai lavorando a qualcosa in cui un pasticcio non sarà la fine del mondo, probabilmente meno copertura andrà bene. Transazioni finanziarie? Molte. Se hai un team di sviluppatori forti che conoscono la base di codice, lavorano bene insieme e non c'è turnover, probabilmente avrai bisogno di meno copertura. Eccetera.

Quindi probabilmente avrà qualche funzione

• Dimensione / fatturato della squadra
• Periodo di validità desiderato dell'applicazione
• L'applicazione e la gravità degli errori
• Tempo concesso per implementare le migliori pratiche relative al programma di sviluppo
• Attitudine del team (questo non significa che essere un buon programmatore significa che non dovresti scrivere unit test, ma una squadra senza sviluppatori junior potrebbe essere in grado di volare al posto dei pantaloni con maggior successo)

Ci sono molte situazioni in cui non sarebbe accettabile scrivere unit test. TDD è "in" in questo momento, ma non è un proiettile d'argento.

È professionale scrivere test di unità mantenibili che ti faranno risparmiare tempo e lacrime!

C'è un misconception that Unit test finds bugs. Bene, questo semplicemente NON è vero per tutti i casi. Il test unitario non riguarda la ricerca di bug o il rilevamento di regressioni. E 'per definizione, examine each unit of your code separately. Ma quando l'applicazione funziona davvero, tutte quelle unità devono lavorare insieme e il tutto è più complesso e sottile della somma delle sue parti testate in modo indipendente.

Pertanto, l'obiettivo del test unitario (nell'ambito del processo TDD) è la progettazione robusta di componenti software.

Modifica: esiste un'eccezione in cui i test unitari rilevano effettivamente i bug. È quando stai eseguendo il refactoring o ristrutturando il codice di un'unità, ma senza significato cambiarne il comportamento. In questo caso, i test unitari possono spesso dirti se il comportamento dell'unità è cambiato.

Come sviluppatore professionista, è accettabile non scrivere unit test?

No.

Senza dubbio - Questa dovrebbe essere una delle prime lezioni che apprende da una persona più fresca. È necessario sviluppare test unitari per dimostrare che il codice funziona prima di comunicare al QA che il codice è pronto per il test. In caso contrario, si aumenterebbero i costi per il progetto e si abbasserebbe il morale del team.

Quanto devono essere accurati questi test unitari?

Ecco la cartina di tornasole: se il QA scopre un bug nel tuo codice, ti sentirai a tuo agio nell'utilizzare i tuoi test di unità per dimostrare la dovuta diligenza al tuo capo?

Se la tua risposta è "No", allora dovresti creare un test unitario (o test) migliore.
Se la tua risposta è "Sì", il tuo codice è pronto per la verifica.

Come sviluppatore professionista, è accettabile non scrivere test unitari automatizzati ?

Sì.

Soprattutto se il tempo e lo sforzo spesi per scrivere test unitari automatici supererebbero i benefici ottenuti dal test. Questo include, ma non è limitato a, codice UI che può essere difficile da deridere.

Enfasi: Sto non dicendo che è impossibile scrivere unit test automatizzati per il codice utente. Sto solo dicendo che, nella mia esperienza, a volte è difficile scrivere test di unità automatizzati per un codice dell'interfaccia utente.