Quanto deve essere grande il mio progetto per poterlo provare unitamente? [chiuso]

Presumo che il mio progetto sia abbastanza disaccoppiato da consentire il collaudo delle unità. Ma quanto grande, esattamente, in termini di clasi e funzioni deve essere il mio progetto per rendere utile il test unitario?

Tutti commettiamo errori e nessuno è perfetto, ma mi considero un programmatore decente per gestire gli errori di piccoli progetti con il passaggio. Oppure i test unitari sono una necessità ardua, indipendentemente dalle dimensioni del progetto?

Il tuo progetto è già abbastanza grande.

Nella mia esperienza, una classe e una funzione sono state sufficienti per considerare la necessità di test unitari.

    class Simple {
        boolean reallySimple() {
            return true; // how do we make sure it doesn't change to false?
        }
    }


    class SimpleTest {
        void assertReallySimple() {
            // ensure reallySimple return value isn't changed unexpectedly
            UnitTestFramework.assertTrue(new Simple().reallySimple());
        }
    }

Non ho mai accettato l'idea "devi provare tutto l'unità", anche se ci sono sicuramente persone là fuori che hanno (vedi la risposta di Gnat !).

Per quanto mi riguarda, i principali vantaggi dei test unitari sono:

1. Aiutare a garantire che i cambiamenti non rompano le cose.
2. Aiutarti a progettare interfacce sensibili per le tue classi (poiché ti costringe a essere un client per il tuo codice).
3. Aiutare a documentare come dovrebbe essere usato il codice.

Fondamentalmente è necessario valutare il tempo necessario per scrivere e mantenere i test su questi fattori.

Il numero 1 è di solito sufficiente per valere la pena di scrivere test. Nella mia esperienza, prima o poi> 95% del codice viene modificato.

È semplice: non hai bisogno di test unitari se scarterai il programma dopo averlo eseguito una volta.

Se questo ti sembra eccessivo, considera cosa significherebbe l'alternativa. Se ci fossero delle dimensioni al di sotto delle quali i test unitari non pagano, dovresti continuare a giudicare nella tua mente: "Ho già raggiunto la dimensione magica? Dovrei iniziare a scrivere test?" Ora, i programmatori sono notoriamente cattivi nel predire il futuro e notoriamente cattivi nel giudicare la propria abilità. Il codice che ti appare cristallino ora diventerà incomprensibile, anche per te, anche aspettando un mese. Un progetto di cui sei assolutamente, assolutamente sicuro, non verrà mai più utilizzato e che ti aggiri semplicemente sulla remota possibilità che potresti voler cercare come hai risolto qualcosa in precedenza, verrà richiesto di nuovo e riceverai richieste di modifica.

È quindi molto probabile che tu giudichi erroneamente se i test sono utili o meno e quando inizi a necessitare di test, non sei già sicuro al 100% di quali siano esattamente la semantica esatta da testare. Poiché ritengo che tutti, tranne i banali programmi una tantum, traggano profitto dai test unitari, considero trascurabili i costi di uno sforzo prolungato nei test che non vengono mai più eseguiti a fronte dei rischi di estendere il codice non testato e compreso male.

Qualche tempo fa ho trovato un bel post: perché i test unitari accelerano lo sviluppo . Può aiutarti a rispondere alla domanda.

... E se al codebase ... fosse fornita una serie sostanziale di test unitari. Un set che direbbe: "se tutti i test hanno esito positivo, garantisco che il codice fa ancora quello che dovrebbe fare" e se un test fallisce ti mostra esattamente dove un comportamento è rotto. Questo è fantastico, potrei cambiare il codice per aggiungere le cose che voglio senza girovagare se il codice fa ancora quello che dovrebbe fare, ho appena eseguito i test ... e ho fiducia. Questo è un grande mondo come ingegnere del software. Ho notato che avrei potuto avanzare molto più velocemente ...

Io ho fede".

Questo è probabilmente il motivo più importante per cui i test unitari accelerano lo sviluppo in un contesto aziendale.

Posso fidarmi che tutto funziona ancora se tutti i test passano. Se i test falliscono, indicano esattamente dove si trova il problema ...

... devi avere una copertura di test unitaria elevata e buoni test unitari . Quando queste condizioni vengono rispettate ti ritroverai in una situazione in cui lo sforzo di aggiungere nuove funzionalità è quasi indipendente dalla dimensione dell'applicazione e che a lungo termine accelererà lo sviluppo .

Michael Feathers ha introdotto in uno dei suoi libri due modi di lavorare con le modifiche al codice:

• modifica e prega,
• coprire e modificare.

Non importa quanto sia grande la base di codice.

Secondo Kent Beck nella sua risposta alla domanda Stack Overflow Quanto sono profondi i test unitari? , dovresti testare il codice che tendi a sbagliare.

Se in genere non commetto un errore (come impostare le variabili sbagliate in un costruttore), non lo provo.

I test unitari sono implementati per risparmiare tempo e migliorare:

• tracciamento dei bug
• refactoring e / o riscrittura del codice
• test d'integrazione
• test di regressione, ecc.

È indispensabile scrivere unit test per parti del programma relativamente complesse.

Se sei sicuro che scrivere unità di test ora non ti farà risparmiare tempo in futuro, puoi saltarlo. Tuttavia, non lo sai mai, e personalmente non riesco a pensare a un caso in cui è più economico (in termini di tempo, denaro e nervi) non scrivere test unitari, ma invece eseguire tutti i test manualmente.

"Devo provare questo unit" di solito si può rispondere rispondendo alla seguente domanda: "È importante che questa funzione funzioni correttamente ed è importante per me sapere quando smette di funzionare?"

Certo, è molto più complicato di così, ma è un buon modo per iniziare. Alla fine peserai anche se il codice è già in fase di test in virtù dell'utilizzo in un'altra funzione o se il tuo tempo sarebbe meglio speso in un'altra funzione, ecc.

A meno che tu non scriva codice senza testarlo, dovrai sempre sostenere i costi del test.

La differenza tra avere unit test e non averli è la differenza tra il costo di scrivere il test e il costo di eseguirlo rispetto al costo del test a mano.

Se il costo per scrivere un test unitario è di 2 minuti e il costo per l'esecuzione del test unitario è praticamente pari a 0, ma il costo per testare manualmente il codice è di 1 minuto, si interrompe anche quando si è eseguito il test due volte.

Per molti anni ho avuto il malinteso di non avere abbastanza tempo per scrivere test unitari per il mio codice. Quando scrivevo i test, erano cose gonfie e pesanti che mi incoraggiavano solo a pensare che avrei dovuto scrivere sempre unit test solo quando sapevo che erano necessari.

Di recente sono stato incoraggiato a utilizzare Test Driven Development e l'ho trovato una rivelazione completa. Ora sono fermamente convinto di non avere il tempo di non scrivere unit test .

Nella mia esperienza, sviluppando pensando ai test, si ottengono interfacce più pulite, classi e moduli più mirati e in genere più codice SOLID , testabile.

Ogni volta che lavoro con un codice legacy che non ha test unitari e devo testare manualmente qualcosa, continuo a pensare "questo sarebbe molto più veloce se questo codice avesse già dei test unitari". Ogni volta che devo provare ad aggiungere funzionalità di unit test al codice con elevato accoppiamento, continuo a pensare "sarebbe molto più facile se fosse stato scritto in modo disaccoppiato".

TL; versione DR :

Scrivi un test quando è probabile che il costo di scrittura del test, oltre al costo di eseguirlo tutte le volte che è necessario, sia inferiore al costo di testarlo manualmente tutte le volte che è necessario.

Ricorda però che se usi TDD, è probabile che il costo della scrittura dei test diminuisca man mano che migliorerai e, a meno che il codice non sia assolutamente banale, probabilmente finirai per eseguire i test più spesso di quanto ti aspetti.

Esegui il test non appena noti le regressioni o la paura di causarne alcune con le tue modifiche e senza accorgertene.

Kindle che temono, lascia che cresca a una dimensione adeguata: prima testerai, meglio è.

Nota: a seconda del ruolo svolto nel progetto, i test unitari potrebbero non essere l'unico tipo di test che si desidera scrivere.

Tutti sono giustamente ossessionati dai test unitari , a causa delle cattive pratiche di test tradizionali in passato; ma se non hai mai testato prima, dovresti davvero concentrarti sui test in generale , i test unitari da soli non risolveranno i problemi del mondo.

Credo che non siano le dimensioni del progetto, ma il tipo di progetto che decide se utilizzare i test o meno.

Se stai lavorando su una prova di concetto o su qualche altro progetto in cui l'obiettivo è quello di imparare dalla codifica, non è necessario testare. Se il progetto è pensato per essere utilizzato, forse anche inviato in produzione, allora dovrebbe essere testato.

Una citazione dal "Clean Code" di Robert C. Martin : "Se è banale scrivere, è banale testare", quindi non ci sono scuse per saltare i test per programmi brevi e banali.

Non è davvero una questione di dimensioni, è quello che ci fai (e quanti anni ha). Se sto cercando di capire come funziona una tecnologia e sto pianificando di buttare via la cosa (la chiamiamo un picco in Scrum), scriverò semplicemente il codice senza fare molti test. Se stai pianificando di svilupparlo ulteriormente (anche se stai solo scherzando), dovresti scrivere test attorno al codice. TDD è una tecnica di progettazione ancor prima di essere una tecnica di prova. Volete avere un quadro chiaro di ciò che volete che faccia il codice prima di rimanere legati ai dettagli dell'esecuzione. Anche io NONconsiglia di provare a scrivere test unitari approfonditi su grandi quantità di codice legacy. Prova a identificare quelle parti che sono complesse (hanno un'elevata complessità ciclomatica / codice spaghetti) e quelle parti che falliscono frequentemente (saranno spesso le stesse). Come altri hanno suggerito, andrei a leggere il libro di Kent Beck su TDD e sicuramente leggerò il libro di Michael Feather. Ciò che non coprono molto è l' aspetto politico nello scrivere unit test attorno al codice. Molti sviluppatori odiano dover modificare il proprio codice per renderlo testabile e molti sviluppatori non sentono affatto la necessità di testare il codice. È qualcosa su cui dobbiamo lavorare come professione. Ogni altra disciplina ingegneristica è tenuta a dimostrare (spesso matematicamente) che il loro lavoro ha soddisfatto le specifiche. Dovremmo fare lo stesso.

Vincolare un progetto nei limiti di classi o funzionalità e poi giudicare se questo è adatto per il test unitario potrebbe essere sbagliato. Ci sono numerosi vantaggi del test unitario di un'applicazione, ma la vera bellezza inizia quando devi mantenere un'applicazione o lavorare in un ambiente distribuito. Quindi la scelta viene qui. Anche una piccola modifica nel codice può causare disastri.
Vorrei non solo suggerire "Unit Testing", ma consiglierei anche di verificare la copertura del codice, assicurando che il massimo del codice sia coperto con Unit Test. La soglia per la copertura del codice non deve essere inferiore al 95% e l'obiettivo deve essere intorno al 100% . Puoi utilizzare gli strumenti per tenere traccia della copertura del codice e generare un rapporto.
Visual Studio fornisce dati sulla copertura -http://msdn.microsoft.com/en-us/library/ms182496(v=vs.80).aspx
Inoltre puoi usare NCover o dotCover.