unit-testing.md

Codice difficile da testare

Codice è difficile da testare quando si ha parti di codice che:

• ha variabili (stato) globali, Singletons
• metodi statici che forzano test su grandi parti di codice, che potenzialmente ha una connessione al database etc.
• troppi conditionals

Come si scrive codice testabili

Sfruttare il TDD per capire man mano che si scrive del codice se è testabile o meno. Questo porta ad applicare principi come dependency injection per passare dipendenze 'mockate' al codice che stiamo testando.

Fasi di test

• Scenario

  • eseguono operazioni per testare l'applicazione dal punto di visto dell'utente
  • sono lenti, non ci danno molto feedback sulla parte del codice in cui il test fallisce
  • si testano soprattutto i 'happy paths', cioè uno scenario in cui l'utente non esegue operazioni non previste

• Functional

  • dipendenze esterne (come IO) vengono simulate
  • testano l'interazione con parti dell'applicazione, testano l'interazione con altre classi

• Unit

  • testano la logica di una singola classe, in isolamento
  • sono velocissimi da eseguire, non toccano IO

Unit testing a class

Abbiamo la necessità di poter scambiare una dipendenza di una classe per renderla testabile in isolamento. Le dipendenza che andremo a sostituire non necessariamente devono essere dei Mock, Stub etc. ma possono anche essere un'istanza di una classe che abbiamo testato in isolamento, e sappiamo che si comporta in un determinato modo.

Per rendere il nostro codice testabili, dobbiamo preoccuparci di separare la logica di dominio dalla logica di costruzione e lookup della nostra applicazione.