Quando dovresti iniziare il test unitario? (durante quale fase di sviluppo?)

Dovresti scrivere i tuoi test unitari molto vicino a quando scrivi il tuo codice. "Tempestivo" è uno dei cinque principi fondamentali del test unitario per Clean Code . Esiste persino un approccio che sostiene di scrivere i tuoi test di unità prima del tuo codice. Si chiama Test Driven o Test First Development, a seconda di chi stai parlando.

Nella mia esperienza, non ha importanza se i test vengono eseguiti prima o secondo, purché i test siano eseguiti prima che il lavoro nel suo complesso sia considerato "fatto". Ciò significa che i test unitari fatti prendono in considerazione la tua storia / attività.

Effettuare i test in prossimità dell'ora in cui esegui il tuo codice ti consente di:

• Scrivi test migliori in quanto ricordi meglio cosa dovrebbe fare il codice. E ti ricordi come fa il codice, rendendo i bug più veloci da risolvere una volta che i tuoi test di unità li trovano.
• Cattura i bug prima, prima che altri usino il tuo codice. Catturare i bug in precedenza significa che sono meno costosi da risolvere.
• Non cadere nella trappola "oh, lo farò dopo"

Puoi iniziare il test delle unità non appena hai un'idea di una classe che desideri creare. Il significato di "unità" dipenderà dal linguaggio di programmazione. Ad esempio, si supponga di voler creare una funzione per analizzare i numeri romani. Potresti iniziare con questo test di unità:

public class RomanTest {
  public void iEquals1() {
    assertEquals(1, Roman.toInteger("I"));
  }
}

Il tuo test non verrà compilato, perché non hai creato la classe romana. Quindi scrivi:

public class Roman {
  public static toInteger(String s) {
    return 1;
  }
}

Wow, il tuo primo test è passato!

Dovresti iniziare a scrivere i tuoi test quando inizi a scrivere il tuo codice.

La parte importante è che qualsiasi codice che scrivi è driven da un test unitario; invece di passare manualmente il codice, fallo con un test. Non ci vuole molto più lavoro per scrivere un test di quanto non faccia il codice.

Scrivendo un test per guidare il tuo codice appena scritto, in pratica acquisisci quel lavoro; se si prova manualmente il codice, tutto lo sforzo si dissipa nell'etere. Se sei, ad esempio, sei mesi che tu o un altro programmatore rompi il codice, quel test sarà lì per salvarti dal dover ripetere lo sforzo di test. Ecco come i test unitari proteggono dalle regressioni!

Nel tempo vedrai i benefici della scrittura di unit test. Un esempio, puoi refactoring il tuo codice e i test unitari ti diranno se hai rotto qualcosa.

Inizia presto! Perché aspettare?

Una volta che il tuo sistema è più complesso di un semplice "Hello, World!" applicazione, puoi iniziare a scrivere test unitari per assicurarti che ciò che hai codificato funzioni correttamente. Se utilizzi uno strumento come Maven per le tue build, puoi fare in modo che i test vengano eseguiti con ogni build, quindi dovresti sapere abbastanza rapidamente se il codice appena scritto ha problemi con il codice esistente.

Vorrei usare il metodo Test-Driven Development se fossi in te.

È piuttosto semplice, tu collaudi il metodo prima che esista, esegui il test. Falliranno. Potrai quindi correggerli facendo funzionare i tuoi metodi.

Dimentica il test dell'unità. Scrivi e metti alla prova te stesso essendo un utente. cerca deliberatamente di infrangere ciò che hai scritto fino al punto di fare cose che non avresti mai fatto, ma qualcun altro poteva farlo. In questo modo scoprirai cose che non potresti prevedere durante la scrittura dei test unitari. I tuoi test unitari, come il tuo codice, hanno senso, ma gli utenti sono liberi da tali restrizioni. Invita spesso alcuni utenti a testare mentre vai. Assicurati che le tue istruzioni siano comprensibili coinvolgendo gli utenti, cosa che i test di unità non possono fare. crea una classe o anche una funzione, provalo ora! Non andare avanti finché non sei soddisfatto che sia ben fatto.