Come utilizzare i test unitari come fonte di informazioni?

Se stai applicando TDD, ogni test unitario che hai scritto corrisponde a una funzionalità di una classe. Quindi mentre scrivi i test, in realtà stai creando le funzionalità di classe, le dipendenze, le eccezioni e anche la documentazione di classe.

Se non stai applicando TDD, i test unitari ti danno un'idea della classe e di cosa fa. I nomi dei test unitari sono molto descrittivi quindi non è necessario creare una documentazione per lo più.

Considera un test unitario come

public void Customer_Service_Can_Register_New_Customers(){...}
public void Customer_Service_Cannot_Register_Customers_With_Duplicate_Emails(){...}

Questi sono metodi auto-descrittivi e facili da leggere. Quindi servono anche come documentazione.

I test unitari, se ben scritti, servono come documentazione di una classe o di un metodo o altro.

Le parole ben scritte portano ad una maggiore comprensione essendo facili da capire su cosa stanno testando, ma anche i test scadenti danno al lettore un'idea di come si suppone che la cosa testata agisca e quali sono le cose che l'autore pensava fossero importanti per prova.

Diamine, sono stato conosciuto per scrivere test unitari per librerie esterne - non perché abbiano bisogno di test, ma perché voglio assicurarmi che la mia comprensione della libreria sia corretta. E in futuro, se qualcuno ha domande su come sto usando le cose, beh, c'è la mia comprensione, proprio nel codice di test.

Sebbene i test funzionali possano aiutarti a comprendere un'intera funzionalità, un test unitario può aiutarti a comprendere un piccolo ambito di codice (come un singolo metodo).

Anche i buoni test unitari funzioneranno come una buona documentazione tecnica, e ci sono alcune cose che possono aiutare a scrivere test buoni, semplici e utili. I due punti più importanti che ho incontrato sono

• Assicurati che tutti i tuoi test siano indipendenti. Dovresti essere in grado di eseguire qualsiasi sottoinsieme di test, in qualsiasi ordine.

• Assicurati di testare una sola cosa in ogni test. Ciò mantiene i tuoi test specifici, semplici, ma non fragili.

L'idea di test come criteri / documentazione di accettazione è eccellente. Tuttavia, i test unitari tendono a focalizzarsi sull'architettura / progettazione del codice piuttosto che sulle storie degli utenti: provare a documentare casi d'uso o requisiti di livello superiore può essere difficile. Non ho ancora approfondito l'argomento (ancora), ma Sviluppo guidato dal comportamento può essere d'aiuto per questo problema.

Trovo che gli esempi siano molto più facili da imparare rispetto alla documentazione e i test unitari sono perfetti. Non solo, ma mi mostrano, ad esempio, cosa NON fare con un'unità.

Tuttavia, non possono essere l'unica forma di documentazione. Bisogna rendersi conto che i cervelli lavorano tutti in modo diverso. Questa è una cosa che penso che le persone che consigliano di utilizzare i test delle unità JUST come documentazione o semplicemente che il codice manchi completamente. Ancora più toccante è il fatto che anche singoli cervelli imparano cose diverse da mezzi diversi. Imparo qualcosa di completamente diverso da un diagramma di classe di quello che sto guardando al codice o leggendo i documenti API.

Ma alla fine della giornata, se i diagrammi e i documenti API sono tutto ciò che hai, probabilmente sono fottuto. Ho bisogno di esempi. Ho bisogno di vedere qualcosa che viene usato. Potrei cercare il codice per questo, e senza altri esempi è quello con cui sono bloccato, ma questo non mi dirà mai più di un buon test unitario.

I test di oggi sono tutti problemi di terminologia in cui persone diverse significano cose leggermente diverse e le definizioni sono cambiate nel tempo.

Ad esempio, TDD era qualcosa che ora è chiamato BDD. La distinzione è dovuta al fatto che ciò che è stato un test unitario attraverso lo sviluppo basato su test è ora un approccio molto più fine ai metodi di test (generalmente generato da strumenti automatici). Quello che era TDD era un modo un po 'più grossolano per testare le unità della dimensione delle classi, che a mio avviso è ora chiamata test funzionale.

L'idea che puoi usare (qualche forma di) test è che puoi scrivere un test che assomigli a come l'utente userebbe un'unità del tuo codice. Diventa un esempio per i documenti e un test allo stesso tempo.

Quindi, se tu avessi una semplice classe di rete (per esempio). Anziché testare singolarmente ciascun metodo, ti verrebbe in mente che la classe è l'unità che ha bisogno di essere testata. Quindi il tuo test unitario eserciterebbe l'intera unità chiamando il metodo per inizializzare l'oggetto, impostando l'host e la porta, e chiamando un metodo per inviare dati, eventualmente chiamando un metodo per ricevere anche.

Tutto ciò che può essere contenuto in un singolo 'unit test' che testerebbe l'oggetto impostandolo in uno stato configurato e facendolo funzionare. Ulteriori test unitari potrebbero esercitarlo con dati errati, ma non è necessario inserirli nella documentazione.

Questo non è considerato un test unitario oggi, ma tutto si riduce alla tua definizione di unità.