Unit Testing

947 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
947
On SlideShare
0
From Embeds
0
Number of Embeds
320
Actions
Shares
0
Downloads
14
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Unit Testing

  1. 1. Unit TestingGiacomo Petronio – O3 Enterprisehttps://github.com/hijackit/swtesting
  2. 2. Intro Software Testing:◦ È una buona idea?◦ Processo costoso tempo, conoscenza manutenzione Vantaggi??
  3. 3. Perché (1) QA Software Di Qualità!◦ Correttezza, robustezza, affidabilità, …◦ Manutenibilità evolutiva, correttiva, riusabilità 1 Bug  meno qualità! N Bug  …
  4. 4. Perché (2) Domanda: perché? Risposta: per verificare che ‘funziona’.
  5. 5. ProblemaProgramma(soluzione)Problemarisolto?Funziona?? Troppo generico.. Quand’è che funziona? Quando saprò se risolve il mio problema?Si da per scontato che saremo in grado didire se la nostra soluzione funziona
  6. 6. Quando funziona? Soddisfa i requisitiInsieme dei requisiti Soluzione problema Programma funziona1° step: definizione dei requisitiContratto che il SW deve rispettare
  7. 7. I test possono essere considerati come un modoper catturare e implementare i requisitiRequisiti e test Una cosa sola 1 requisito  1+ test 1 requisito, 0 test == 0 requisiti
  8. 8. Categorie di test Test di accettazione (Stress test) Test funzionali Test di integrazione Unit testCriterio: Oggetto sotto verifica Scopo della verifica
  9. 9. Unit test Scopo: “funziona”? Oggetto: singola classe Altre caratteristiche:◦ Code coverage
  10. 10. Unit test API Design Documentazione vivente
  11. 11. Unit test Refactoring Code confidence Regression testing
  12. 12. Definire Unit Test Non dovrebbe◦ Comunicare con DBMS/rete/filesystem◦ Aver bisogno di un ambiente configurato Dovrebbe essere◦ Veloce◦ Ripetibile◦ Indipendente
  13. 13. Definire Unit Test Meno pignoli!◦ Può accedere a DBMS (in-memory dbms)◦ Può accedere al filesystem◦ Può accedere alla reteVelocità Ripetibilità Indipendenza
  14. 14. xUnit JUnit CppUnit NUnit PHPUnit PyUnit …
  15. 15. Idea di base La ricetta per un buon test◦ Fixture (contesto)◦ Test case◦ CheckKent Beck’s testing framework paperhttp://www.xprogramming.com/testfram.htm
  16. 16. JUnit MyClassTest◦ Fixture: @Before method◦ Test Case: @Test method◦ Check assertESEMPIO…
  17. 17. Best practices N model classes  N test classes Assert precisiassertTrue(shape.area != 0);assertTrue(shape.area == 50);
  18. 18. Best practices White box / Black boxProcess proc = new Process();proc.start();assertEquals(proc.status, Status.Running);assertTrue(proc.isRunning());
  19. 19. Best practices Come testare metodi privati◦ non testare◦ reflection◦ cambiare visibilità◦ (nested test-class)ReflectionLegacy code?Non testareCodice nuovo?Visibilità defaultNuova classe
  20. 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. 21. Best practices Nome test-case (metodi)◦ Verbosità è oktest01(){ … }test02(){ … }testAreaIsEmpty(){ … }testTriangleIsNotARectangle(){ … }areaShouldBeEmpty(){ … }areaShouldBeExactly50(){ … }triangleShouldNotBeEqualToARectangle(){ … }
  22. 22. Best practices Eccezioni◦ Attributo expected@Test(expected=IllegalArgumentException.class)invaldAddressShouldNotBeAccepted(){WebClient client = new WebClient(“WRONG!”);}@TestinvaldAddressShouldNotBeAccepted(){try{WebClient client = new WebClient(“WRONG!”);fail();} catch(IllegalArgumentException e){}}
  23. 23. Tecniche di testing Classi di equivalenza e valori al confine◦ Coprire tutti gli input◦ Minimizzare la ridondanza0 6 16 654€0€ 8€ 5€5 test-case, uno per classe di equivalenza8 test-case, uno per confine di ciascuna classe
  24. 24. Tecniche di testing Esplorazione del grafo◦ Macchine a stato◦ Transazioni e stato internoint left = 1;int right = 1;public void incLeft(){ left++; }public void incRight(){ right++; }public String getId(){return left + “.” + right;}
  25. 25. Tecniche di testing1:12:13:1 1:21:22:1 1:3T1 T2Stato iniziale X;Y X;YEvento incLeft incRightEffetto X++ Y++Stato finale X+1;Y X;Y+11° livello: 2 test-case2° livello: 4 test-case3° livello: 8 test-case…T1 T2
  26. 26. Codice testabile SOLID principles◦ Single responsibility◦ Open/Closed
  27. 27. Codice testabile SOLID principles◦ Liskov substitutionAClass {client.doGreatThings();}Client {…}SubClient extends Client {…}
  28. 28. Codice testabile SOLID principles◦ Interface segregationIDoOneThing {doOneThingA();}IDoManyThings {doThingA();doThingB();doThingC();}IDoAnotherThing {doOneThingB();}
  29. 29. Codice testabile SOLID principles◦ Dependency inversionclass JapaneseGuy {playWith(PlayStation ps){ps.play();}}class JapaneseGuy {playWith(IConsolle c){c.play();}}Concrete, AbstractConcrete Abstract
  30. 30. EsempioMovieLister+ moviesDirectedBy<<Interface>>MovieFinder+ findAll()MovieFinderImpl<<crea>>Classe concreta usa classe concretahttp://martinfowler.com/articles/injection.html
  31. 31. Testare una classe Isolare la classe◦ Individuare tutte le dipendenze◦ Prendere il controllo (IoC) Classe testabile◦ Poche dipendenze◦ Dipendenze astratte
  32. 32. Inversion Of Control (IoC) Dipendenze vengono fornite Diversi pattern◦ Dependency Injection (DI)MovieLister<<Interface>>MovieFinderMovieFinderImpl<<crea>>Assembler <<crea>><<inject>>
  33. 33. IoC: Dependency Injection Constructor injection◦ Dipendenze esplicite Setter injection◦ Dipendenze meno esplicite◦ Rende testabile classe esistente Framework…◦ Guice◦ Spring◦ CDI (J2EE 6)
  34. 34. IoC: Service LocatorMovieLister<<Interface>>MovieFinderMovieFinderImpl<<crea>>ServiceLocator Assembler<<crea>><<chiede>>
  35. 35. DI Framework: Guice Es. servizio di pagamentohttps://code.google.com/p/google-guice/wiki/MotivationRealBillingService<<Interface>>CreditCardProcessorPaypalProcessor<<Interface>>TransactionLogDBTransactionLog<<Interface>>BillingService+ chargeOrder(order, creditCard)
  36. 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. 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. 38. Mocking library: Mockito Mock lifecycle:◦ Crea mock a partire da interfaccia◦ Programma comportamento atteso◦ Utilizzo indiretto (da parte del SUT*)◦ Verifica dell’utilizzoSUT = System Under Test, classe sottoposta a verifica
  39. 39. Mockito: esempioMovieFinder finder = mock(MovieFinder.class)when(finder.findAll()).thenReturn(allMovies);MovieLister lister = new MovieLister(finder);Lister.moviesDirectedBy(“Martin Scorsese”);verify(finder).findAll(); // verifica la chiamataESEMPIO…
  40. 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. 41. Mockito: spiesList list = new ArrayList();List spy = spy(list);// calls real method!spy.add(“one”);spy.add(“two”);// verifyverify(spy).add("one"); Utile per testare codice esistente
  42. 42. Test di risorse web Esempio con Jetty (OnlineMovieFinder)OnlineMovieFinder Risorsa webTesterJetty ServerServlet StubESEMPIO…
  43. 43. Test Driven Development Test first! TDD mantra:◦ RED◦ GREEN◦ REFACTOR
  44. 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° test2° test3° test
  45. 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 scrivereThe real value of unit testing is that it forcesyou to stop and think about testing.

×