Il documento tratta dell'importanza dei test unitari nel processo di sviluppo software, sottolineando come questi possano migliorare la qualità del software attraverso la verifica della correttezza e la manutenibilità. Vengono discusse le best practices e le tecniche di testing per garantire che il codice sia testabile, incluso l'uso di framework come JUnit e Mockito. Inoltre, il documento promuove lo sviluppo guidato dai test (TDD) come metodo efficace per affrontare le problematiche e garantire la funzionalità del software.

1. Unit Testing
Giacomo Petronio – O3 Enterprise
https://github.com/hijackit/swtesting

2. Intro
 Software Testing:
◦ È una buona idea?
◦ Processo costoso
 tempo, conoscenza
 manutenzione
 Vantaggi??

3. Perché (1) QA
 Software Di Qualità!
◦ Correttezza, robustezza, affidabilità, …
◦ Manutenibilità evolutiva, correttiva, riusabilità
 1 Bug  meno qualità!
 N Bug  …

4. Perché (2)
 Domanda: perché?
 Risposta: per verificare che ‘funziona’.

5. Problema
Programma
(soluzione)
Problema
risolto?
Funziona??
 Troppo generico..
 Quand’è che funziona?
 Quando saprò se risolve il mio problema?
Si da per scontato che saremo in grado di
dire se la nostra soluzione funziona

6. Quando funziona?
 Soddisfa i requisiti
Insieme dei requisiti
 Soluzione problema
 Programma funziona
1° step: definizione dei requisiti
Contratto che il SW deve rispettare

7. I test possono essere considerati come un modo
per catturare e implementare i requisiti
Requisiti e test
 Una cosa sola
 1 requisito  1+ test
 1 requisito, 0 test == 0 requisiti

8. Categorie di test
 Test di accettazione
 (Stress test)
 Test funzionali
 Test di integrazione
 Unit test
Criterio:
 Oggetto sotto verifica
 Scopo della verifica

9. Unit test
 Scopo: “funziona”?
 Oggetto: singola classe
 Altre caratteristiche:
◦ Code coverage

10. Unit test
 API Design
 Documentazione vivente

11. Unit test
 Refactoring
 Code confidence
 Regression testing

12. Definire Unit Test
 Non dovrebbe
◦ Comunicare con DBMS/rete/filesystem
◦ Aver bisogno di un ambiente configurato
 Dovrebbe essere
◦ Veloce
◦ Ripetibile
◦ Indipendente

13. Definire Unit Test
 Meno pignoli!
◦ Può accedere a DBMS (in-memory dbms)
◦ Può accedere al filesystem
◦ Può accedere alla rete
Velocità Ripetibilità Indipendenza

14. xUnit
 JUnit
 CppUnit
 NUnit
 PHPUnit
 PyUnit
 …

15. Idea di base
 La ricetta per un buon test
◦ Fixture (contesto)
◦ Test case
◦ Check
Kent Beck’s testing framework paper
http://www.xprogramming.com/testfram.htm

16. JUnit
 MyClassTest
◦ Fixture: @Before method
◦ Test Case: @Test method
◦ Check assert
ESEMPIO…

17. Best practices
 N model classes  N test classes
 Assert precisi
assertTrue(shape.area != 0);
assertTrue(shape.area == 50);

18. Best practices
 White box / Black box
Process proc = new Process();
proc.start();
assertEquals(proc.status, Status.Running);
assertTrue(proc.isRunning());

19. Best practices
 Come testare metodi privati
◦ non testare
◦ reflection
◦ cambiare visibilità
◦ (nested test-class)
ReflectionLegacy code?
Non testareCodice nuovo?
Visibilità default
Nuova classe

20. Best practices
 Nome classe
◦ TriangleTest
 Package
◦ src/main/java/it/units/inginf/shapes
 Triangle.class
 Rectangle.class
◦ src/test/java/it/units/inginf/shapes
 TriangleTest.class
 RectangleTest.class

21. Best practices
 Nome test-case (metodi)
◦ Verbosità è ok
test01(){ … }
test02(){ … }
testAreaIsEmpty(){ … }
testTriangleIsNotARectangle(){ … }
areaShouldBeEmpty(){ … }
areaShouldBeExactly50(){ … }
triangleShouldNotBeEqualToARectangle(){ … }

22. Best practices
 Eccezioni
◦ Attributo expected
@Test(expected=IllegalArgumentException.class)
invaldAddressShouldNotBeAccepted(){
WebClient client = new WebClient(“WRONG!”);
}
@Test
invaldAddressShouldNotBeAccepted(){
try{
WebClient client = new WebClient(“WRONG!”);
fail();
} catch(IllegalArgumentException e){}
}

23. Tecniche di testing
 Classi di equivalenza e valori al confine
◦ Coprire tutti gli input
◦ Minimizzare la ridondanza
0 6 16 65
4€0€ 8€ 5€
5 test-case, uno per classe di equivalenza
8 test-case, uno per confine di ciascuna classe

24. Tecniche di testing
 Esplorazione del grafo
◦ Macchine a stato
◦ Transazioni e stato interno
int left = 1;
int right = 1;
public void incLeft(){ left++; }
public void incRight(){ right++; }
public String getId(){
return left + “.” + right;
}

25. Tecniche di testing
1:1
2:1
3:1 1:2
1:2
2:1 1:3
T1 T2
Stato iniziale X;Y X;Y
Evento incLeft incRight
Effetto X++ Y++
Stato finale X+1;Y X;Y+1
1° livello: 2 test-case
2° livello: 4 test-case
3° livello: 8 test-case
…
T1 T2

26. Codice testabile
 SOLID principles
◦ Single responsibility
◦ Open/Closed

27. Codice testabile
 SOLID principles
◦ Liskov substitution
AClass {
client.doGreatThings();
}
Client {
…
}
SubClient extends Client {
…
}

28. Codice testabile
 SOLID principles
◦ Interface segregation
IDoOneThing {
doOneThingA();
}
IDoManyThings {
doThingA();
doThingB();
doThingC();
}
IDoAnotherThing {
doOneThingB();
}

29. Codice testabile
 SOLID principles
◦ Dependency inversion
class JapaneseGuy {
playWith(PlayStation ps){
ps.play();
}
}
class JapaneseGuy {
playWith(IConsolle c){
c.play();
}
}
Concrete, Abstract
Concrete Abstract

30. Esempio
MovieLister
+ moviesDirectedBy
<<Interface>>
MovieFinder
+ findAll()
MovieFinderImpl
<<crea>>
Classe concreta usa classe concreta
http://martinfowler.com/articles/injection.html

31. Testare una classe
 Isolare la classe
◦ Individuare tutte le dipendenze
◦ Prendere il controllo (IoC)
 Classe testabile
◦ Poche dipendenze
◦ Dipendenze astratte

32. Inversion Of Control (IoC)
 Dipendenze vengono fornite
 Diversi pattern
◦ Dependency Injection (DI)
MovieLister
<<Interface>>
MovieFinder
MovieFinderImpl
<<crea>>
Assembler <<crea>>
<<inject>>

33. IoC: Dependency Injection
 Constructor injection
◦ Dipendenze esplicite
 Setter injection
◦ Dipendenze meno esplicite
◦ Rende testabile classe esistente
 Framework…
◦ Guice
◦ Spring
◦ CDI (J2EE 6)

34. IoC: Service Locator
MovieLister
<<Interface>>
MovieFinder
MovieFinderImpl
<<crea>>
ServiceLocator Assembler
<<crea>>
<<chiede>>

35. DI Framework: Guice
 Es. servizio di pagamento
https://code.google.com/p/google-guice/wiki/Motivation
RealBillingService
<<Interface>>
CreditCardProcessor
PaypalProcessor
<<Interface>>
TransactionLog
DBTransactionLog
<<Interface>>
BillingService
+ chargeOrder(order, creditCard)

36. Stub e Mock
 Isolare la classe
 Se ha dipendenze?
◦ Sostituirle con oggetti controllati
 Stub
◦ Non hanno logica interna
◦ Comportamento sempre uguale
◦ Non si effettuano verifiche sugli stub
◦ Es. finta risorsa web

37. Stub e Mock
 Mock
◦ Programmabile
 Quando metodo riceve X
 Restituisci Y
 Lancia eccezione
 …
◦ Verifiche sui mock
 Numero di chiamate ad un metodo
 Parametro passato ad un metodo
 …

38. Mocking library: Mockito
 Mock lifecycle:
◦ Crea mock a partire da interfaccia
◦ Programma comportamento atteso
◦ Utilizzo indiretto (da parte del SUT*)
◦ Verifica dell’utilizzo
SUT = System Under Test, classe sottoposta a verifica

39. Mockito: esempio
MovieFinder finder = mock(MovieFinder.class)
when(finder.findAll()).thenReturn(allMovies);
MovieLister lister = new MovieLister(finder);
Lister.moviesDirectedBy(“Martin Scorsese”);
verify(finder).findAll(); // verifica la chiamata
ESEMPIO…

40. Mockito: possibilità
MovieFinder finder = mock(MovieFinder.class)
when(finder.findAll()).___________
.thenReturn(allMovies);
.thenReturn(none, all);
.thenThrows(new RuntimeException());
.then( callback );
MovieLister lister = mock(MovieLister.class)
when(lister.moviesDirectedBy(_____)).then(…);
“Martin Scorsese”
anyString()
any()

41. Mockito: spies
List list = new ArrayList();
List spy = spy(list);
// calls real method!
spy.add(“one”);
spy.add(“two”);
// verify
verify(spy).add("one");
 Utile per testare codice esistente

42. Test di risorse web
 Esempio con Jetty (OnlineMovieFinder)
OnlineMovieFinder Risorsa web
Tester
Jetty Server
Servlet Stub
ESEMPIO…

43. Test Driven Development
 Test first!
 TDD mantra:
◦ RED
◦ GREEN
◦ REFACTOR

44. Test Driven Development
 Ho un metodo calcolaX(a, b)
 Ho bisogno di un test che verifica TUTTO!
 Dati a, b vorrei ottenere X
 Se a < 0, vorrei avere un errore
 Se b == 0, vorrei…
1° test
2° test
3° test

45. Test Driven Development
 What is the common, expected case?
 What are some possible unusual cases?
 How many external dependencies do I have?
 What system failures could I reasonably encounter here?
http://www.codinghorror.com/blog/2005/04/good-test-bad-test.html
 Costringe ad affrontare domande scomode
 Costringe a pensare prima di scrivere
The real value of unit testing is that it forces
you to stop and think about testing.