Cosa Testare?

Quando si scrivono gli unit test ci si chiede spesso se ha senso testare o meno una certa funzionalità. Un esempio classico è "Devo testare tutti i getter e setter delle proprietà della mia classe?" La risposta è in genere no sempre che il get (o set) non contenga alcuna logica ma sia un semplice "return value".

Alcune persone con cui ho parlato dicono di testare comunque anche i getter e setter perché anche se adesso non fanno altro che mappare un private field non è detto che in futuro diventino qualcosa di più articolato, con regole di validazione sul dato e/o costruzione dello stesso (ad esempio per formattarlo). Anche se questo è vero rompe una delle regole delle metodologie agili che dice più o meno "non fare oggi quello che forse dovrai fare domani".

Quindi la mia posizione rimane sul testare solo ciò che contiene logica applicativa.

Altro dubbio che spesso viene sollevato è sulla necessità o meno di testare i metodi privati di una classe. Anche qui ci sono pareri contrastanti (e alcuni framework che lo permettono). Io ritengo che ciò che è privato non vada testato in quanto a noi utilizzatori della classe non interessa quello che avviene internamente: una classe ha un'interfaccia pubblica che fornisce le sue funzionalità e sono quelle che dobbiamo testare.

 Stabilito quanto sopra rimane da capire come testare un metodo pubblico. Le regole generali da seguire sono le seguenti:

  1. Testare che il metodo faccia quello per cui è stato scritto, ossia che i risultati siano corretti. Questa è la regola principale.
  2. Testare gli estremi. Spesso un metodo viene testato con dati validi e "normali", ma è buona regola testare anche con i dati in ingresso "speciali". Ad esempio un metodo riceve come input una stringa? Provate a passargli la stringa vuota. Riceve un intero? Passategli 0, -1, Int32.MaxValue, ecc…
  3. Testare gli errori. Il vostro codice genera un'eccezione quando i parametri d'ingresso hanno valori particolari? Allora sono da testare, dovete verificare che quando il parametro assume quel valore l'eccezione viene effettivamente generata.
  4. Fare il possibile affinché il test sia atomico e testi un'unica funzionalità. Se volete testare più cose dello stesso metodo (io sentirei puzza!) scrivete più test.

     

    Seguite altre regole? Fatemelo sapere.

Print | posted on Thursday, March 29, 2007 7:34 PM