In che modo i test unitari facilitano la progettazione?

Il nostro collega promuove la scrittura di test di unità come in realtà ci aiuta a perfezionare il nostro design e le cose del refactor, ma non vedo come. Se sto caricando un file CSV e lo analizzo, in che modo unit test (convalida dei valori nei campi) mi aiuterà a verificare il mio progetto? Ha menzionato l'accoppiamento, la modularità ecc., Ma per me non ha molto senso - ma non ho molti retroscena teorici.

Non è la stessa della domanda che hai contrassegnato come duplicato, sarei interessato ad esempi concreti su come questo aiuta, non solo alla teoria che dice "aiuta". Mi piace la risposta qui sotto e il commento, ma vorrei saperne di più.

Non solo i test unitari facilitano la progettazione, ma questo è uno dei loro principali vantaggi.

Scrivere test-first elimina la modularità e la struttura pulita del codice.

Quando scrivi il tuo codice test-first, scoprirai che qualsiasi "condizione" di una determinata unità di codice viene naturalmente espulsa alle dipendenze (di solito tramite mock o stub) quando le assumi nel tuo codice.

"Data condizione x, aspettarsi comportamento y" diventerà spesso uno stub da fornire x(che è uno scenario in cui il test deve verificare il comportamento del componente corrente) e ydiventerà un mock, una chiamata a cui verrà verificato all'indirizzo la fine del test (a meno che non sia un "dovrebbe restituire y", nel qual caso il test verificherà semplicemente il valore restituito in modo esplicito).

Quindi, una volta che questa unità si comporta come specificato, si passa alla scrittura delle dipendenze (per xe y) scoperte.

Ciò rende la scrittura di codice pulito e modulare un processo molto semplice e naturale, dove altrimenti è spesso facile confondere le responsabilità e accoppiare i comportamenti senza rendersene conto.

Scrivere test in seguito ti dirà quando il tuo codice è scarsamente strutturato.

Quando scrivere test per un pezzo di codice diventa difficile perché ci sono troppe cose da stubare o deridere, o perché le cose sono troppo strettamente accoppiate insieme, sai che hai miglioramenti da apportare al tuo codice.

Quando "cambiare i test" diventa un peso perché ci sono così tanti comportamenti in una singola unità, sai che hai miglioramenti da apportare nel tuo codice (o semplicemente nel tuo approccio alla scrittura dei test - ma questo non è solitamente il caso nella mia esperienza) .

Quando i tuoi scenari diventano troppo complicati ("if xand yand zthen ...") perché devi estrarre di più, sai che hai dei miglioramenti da apportare al tuo codice.

Quando finisci con gli stessi test in due dispositivi diversi a causa della duplicazione e della ridondanza, sai di avere miglioramenti da apportare al tuo codice.

Ecco un eccellente discorso di Michael Feathers che dimostra la stretta relazione tra testabilità e design nel codice (originariamente pubblicato da displayName nei commenti). Il discorso affronta anche alcune lamentele comuni e idee sbagliate sul buon design e testabilità in generale.

La cosa grandiosa dei test unitari è che ti permettono di usare il tuo codice come gli altri programmatori useranno il tuo codice.

Se il tuo codice è scomodo per il test unitario, probabilmente sarà scomodo da usare. Se non puoi iniettare dipendenze senza saltare attraverso i cerchi, probabilmente il tuo codice sarà poco flessibile da usare. E se hai bisogno di spendere molto tempo a impostare i dati o a capire in quale ordine eseguire le cose, il tuo codice in prova probabilmente ha troppi accoppiamenti e sarà un problema con cui lavorare.

Mi ci è voluto un po 'di tempo per rendermene conto, ma il vero vantaggio (modifica: secondo me, il tuo chilometraggio può variare) nello sviluppo guidato dai test ( usando i test unitari) è che devi progettare l'API in anticipo !

Un tipico approccio allo sviluppo è innanzitutto capire come risolvere un determinato problema, e con quella conoscenza e la progettazione dell'implementazione iniziale in qualche modo invocare la tua soluzione. Questo può dare alcuni risultati piuttosto interessanti.

Quando fai TDD devi prima scrivere il codice che utilizzerà la tua soluzione. Parametri di input e output previsto in modo da poter essere sicuri che sia corretto. Ciò a sua volta richiede di capire cosa è effettivamente necessario per farlo, in modo da poter creare test significativi. Quindi e solo allora implementerai la soluzione. È anche la mia esperienza che quando sai esattamente cosa dovrebbe raggiungere il tuo codice, diventa più chiaro.

Quindi, dopo che i test unitari di implementazione ti aiutano a garantire che il refactoring non interrompa la funzionalità e fornisci la documentazione su come utilizzare il tuo codice (che sai che è giusto al superamento del test!). Ma questi sono secondari: il più grande vantaggio è la mentalità nella creazione del codice in primo luogo.

Concordo al 100% che i test unitari ci aiutano "ci aiutano a perfezionare il nostro design e le cose del refactor".

Ho due idee sul fatto che ti aiutino a fare il progetto iniziale . Sì, rivelano evidenti difetti e ti costringono a pensare a "come posso rendere testabile il codice"? Ciò dovrebbe comportare un minor numero di effetti collaterali, una configurazione e impostazioni più semplici, ecc.

Tuttavia, nella mia esperienza, test di unità eccessivamente semplicistici, scritti prima che tu capisca veramente quale dovrebbe essere il progetto (è vero, è un'esagerazione del TDD hard-core, ma troppo spesso i programmatori scrivono un test prima di pensare molto) spesso portano ad un'anemia modelli di dominio che espongono troppi interni.

La mia esperienza con TDD è stata diversi anni fa, quindi sono interessato a sapere quali nuove tecniche potrebbero aiutare a scrivere test che non pregiudicano troppo il design sottostante. Grazie.

Il test unitario ti consente di vedere come funzionano le interfacce tra le funzioni e spesso ti fornisce informazioni su come migliorare sia la progettazione locale sia la progettazione generale. Inoltre, se si sviluppano i test unitari durante lo sviluppo del codice, si dispone di una suite di test di regressione già pronta. Non importa se stai sviluppando un'interfaccia utente o una libreria di back-end.

Una volta sviluppato il programma (con test unitari), poiché i bug vengono scoperti, è possibile aggiungere test per confermare che i bug sono stati corretti.

Uso TDD per alcuni dei miei progetti. Mi sono impegnata moltissimo nella creazione di esempi tratti da libri di testo o da documenti considerati corretti e testando il codice che sto sviluppando usando questi esempi. Qualsiasi incomprensione che ho riguardo ai metodi diventa molto evidente.

Tendo ad essere un po 'più flessibile di alcuni dei miei colleghi, poiché non mi interessa se il codice viene scritto per primo o il test viene scritto per primo.

Quando si desidera eseguire il test unitario del parser che rileva correttamente la delimitazione del valore, è possibile passare una riga da un file CSV. Per rendere il tuo test diretto e breve potresti voler testarlo attraverso un metodo che accetta una riga.

Questo ti farà automaticamente separare la lettura delle righe dalla lettura dei singoli valori.

Ad un altro livello potresti non voler inserire tutti i tipi di file CSV fisici nel tuo progetto di test ma fare qualcosa di più leggibile, semplicemente dichiarando una grande stringa CSV all'interno del tuo test per migliorare la leggibilità e l'intento del test. Questo ti porterà a disaccoppiare il tuo parser da qualsiasi I / O che faresti altrove.

Solo un esempio di base, inizia a praticarlo, a un certo punto sentirai la magia (ho).

In parole povere, la scrittura di unit test aiuta a mettere in evidenza i difetti del codice.

Questa spettacolare guida alla scrittura di codice testabile , scritta da Jonathan Wolter, Russ Ruffer e Miško Hevery, contiene numerosi esempi di come i difetti del codice, che possono inibire i test, impediscono anche un facile riutilizzo e flessibilità dello stesso codice. Pertanto, se il tuo codice è testabile, è più facile da usare. La maggior parte della "morale" sono suggerimenti ridicolmente semplici che migliorano notevolmente la progettazione del codice ( Dependency Injection FTW).

Ad esempio: è molto difficile verificare se il metodo computeStuff funziona correttamente quando la cache inizia a sfrattare roba. Questo perché devi aggiungere manualmente schifezze alla cache fino a quando il "bigCache" è quasi pieno.

public OopsIHardcoded {

   Cache cacheOfExpensiveComputations;

   OopsIHardcoded() {
       this.cacheOfExpensiveComputation = buildBigCache();
   }

   ExpensiveValue computeStuff() {
      //DOES THIS WORK CORRECTLY WHEN CACHE EVICTS DATA?
   }
}

Tuttavia, quando utilizziamo l'iniezione di dipendenza è molto più semplice verificare se il metodo computeStuff funziona correttamente quando la cache inizia a sfrattare roba. Tutto ciò che facciamo è creare un test in cui chiamiamo new HereIUseDI(buildSmallCache()); Notice, abbiamo un controllo più sfumato dell'oggetto e paga immediatamente i dividendi.

public HereIUseDI {

   Cache cacheOfExpensiveComputations;

   HereIUseDI(Cache cache) {
       this.cacheOfExpensiveComputation = cache;
   }

   ExpensiveValue computeStuff() {
      //DOES THIS WORK CORRECTLY WHEN CACHE EVICTS DATA?
   }
}

Benefici simili possono essere ottenuti quando il nostro codice richiede dati che sono normalmente conservati in un database ... basta passare ESATTAMENTE i dati necessari.

A seconda di cosa si intenda per "Test unitari", non credo che i test unitari di basso livello facilitino un buon design tanto quanto i test di integrazione di livello leggermente superiore - test che testano che un gruppo di attori (classi, funzioni, qualunque cosa) in il codice si combina correttamente per produrre tutta una serie di comportamenti desiderabili concordati tra il team di sviluppo e il proprietario del prodotto.

Se riesci a scrivere test a quei livelli, ti spinge verso la creazione di un codice carino, logico, simile a un'API che non richiede molte dipendenze pazze - il desiderio di avere una semplice configurazione di test ti spingerà naturalmente a non avere un sacco di dipendenze pazze o codice strettamente accoppiato.

Tuttavia, non commettere errori: i test unitari possono portare a una cattiva progettazione, nonché a una buona progettazione. Ho visto gli sviluppatori prendere un po 'di codice che ha già un bel design logico e una singola preoccupazione, e smontarlo e introdurre più interfacce esclusivamente a scopo di test e, di conseguenza, rendere il codice meno leggibile e più difficile da cambiare , oltre a possibilmente anche avere più bug se lo sviluppatore ha deciso che avere molti test unitari di basso livello significa che non devono avere test di livello superiore. Un esempio preferito in particolare è un bug che ho risolto in cui c'era un sacco di codice "testabile" molto scomposto relativo all'ottenimento di informazioni dentro e fuori dagli appunti. Tutto suddiviso e disaccoppiato a livelli molto piccoli di dettaglio, con molte interfacce, molte derisioni nei test e altre cose divertenti. Solo un problema: non esisteva alcun codice che interagisse effettivamente con il meccanismo degli appunti del sistema operativo,

I test unitari possono sicuramente guidare il tuo design, ma non ti guidano automagicamente a un buon design. Devi avere idee su quale sia il buon design che vada oltre il semplice "questo codice è testato, quindi è testabile, quindi è buono".

Naturalmente se sei una di quelle persone per le quali "unit test" significa "eventuali test automatici che non sono guidati attraverso l'interfaccia utente", alcuni di questi avvisi potrebbero non essere così rilevanti - come ho detto, penso che quelli più alti i test di integrazione di livello sono spesso i più utili quando si tratta di guidare il proprio progetto.

I test unitari possono aiutare con il refactoring quando il nuovo codice supera tutti i vecchi test.

Supponiamo che tu abbia implementato un bolle d'aria perché eri di fretta e non preoccupato per le prestazioni, ma ora vuoi una risposta rapida perché i dati si allungano. Se tutti i test passano, le cose sembrano buone.

Naturalmente i test devono essere completi per far funzionare questo. Nel mio esempio, i tuoi test potrebbero non coprire la stabilità perché ciò non riguardava il bolle.

Ho riscontrato che i test unitari sono estremamente utili per facilitare la manutenzione a lungo termine di un progetto. Quando torno a un progetto dopo mesi e non ricordo molti dettagli, l'esecuzione dei test mi impedisce di rompere le cose.