Unit testing 101

download Unit testing 101

If you can't read please download the document

description

Introduzione allo Unit Testing in PHP

Transcript of Unit testing 101

  • 1. Unit testing 101 Introduzione allo Unit Testing in PHP Daniel Londero [email_address]

2. Chi sono Daniel Londero

  • Sviluppatore PHP dal 2005 @

3. (s|S)ymfony framework 4. PUG Friuli 5. GrUSP board 6. Runner 7. Attenzione! Assistere alla seguente presentazione pu avere i seguenti effetti... 8. Unit test Seguiti da 9. Riduzione della pressione arteriosa http://www.flickr.com/photos/fwooper7/4221177229/ 10. Migliore qualit del sonno http://www.flickr.com/photos/paolobosonin/2700153474/ 11. Maggiore tempo libero http://www.flickr.com/photos/73069365@N00/5070251710/ S 12. Maggiore tempo libero http://www.flickr.com/photos/circumerro-stock/3706572178/ 13. Maggiore tempo libero http://www.flickr.com/photos/limaoscarjuliet/822938133/ 14. Unit testing In computer programming, unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application. Ideally, each test case is independent from the others: substitutes like method stubs, mock objects, fakes and test harnesses can be used to assist testing a module in isolation. 15. Unit testing In computer programming, unit testing is a method by whichindividual units of source codeare tested to determine if they are fit for use. A unit is the smallest testable part of an application. Ideally, each test case is independent from the others: substitutes like method stubs, mock objects, fakes and test harnesses can be used to assist testing a module in isolation. 16. Unit testing In computer programming, unit testing is a method by whichindividual units of source codeare tested to determine if they are fit for use. A unit is thesmallest testable partof an application. Ideally, each test case is independent from the others: substitutes like method stubs, mock objects, fakes and test harnesses can be used to assist testing a module in isolation. 17. Unit testing In computer programming, unit testing is a method by whichindividual units of source codeare tested to determine if they are fit for use. A unit is thesmallest testable partof an application. Ideally, each test case is independent from the others: substitutes like method stubs, mock objects, fakes and test harnesses can be used to assisttesting a module in isolation . 18. Scusa #1 Non ho tempo per scrivere i test oppure Potrei lavorare ad altre feature nel frattempo 19. Regola 80/20 Nuovo codice Manutenzione e debug 20. ...vista dalla parte dello sviluppatore Felicit Tristezza 21. Funziona Durantele operazionidi debug il codice testato viene eliminato velocemente. Non sar necessario perdere tempo per farlo funzionare dato che i test garantiscono il suo funzionamento sin dall'inizio. 22. Scusa #2 Nessun altro collega scrive test 23. Da solo... http://www.flickr.com/photos/hryckowian/109004281/ 24. Il diverso... http://www.flickr.com/photos/tyrian123/3147557274/ 25. Ma non siamo ragazzini! http://www.flickr.com/photos/feuilllu/302001867/ 26. ...inoltre Nel paese dei ciechi, chi ha un occhio solo re 27. Scusa #3 Il nostro testing (manuale) gi sufficiente 28. Ah s sicuramente

  • Non salti mai un passaggio

29. Ah s sicuramente

  • Non salti mai un passaggio

30. Non fai mai un errore 31. Ah s sicuramente

  • Non salti mai un passaggio

32. Non fai mai un errore 33. Controllituttii test per ogni modifica 34. Scusa #4 Scrivere i test noioso 35. Pu essere ma... Invece che scriverlituttialla fine basta fare in modo di scriverli prima di implementare la funzionalit (TDD). Il passaggio da scrittura del test a scrittura della feature render tutto pi divertente. 36. Vantaggio #1 Meno bug in produzione 37. Vantaggio #2 Pi tempo per lo sviluppo 38. Vantaggio #3 Test automatici 39. Vantaggio #4 Facile cambiare. Refactoring. 40. Vantaggio #5 Miglior design del codice (TDD) 41. Vantaggio #6 Una forma di documentazione 42. Vantaggio #7 Focus sul problema 43. Vantaggio #8 Fiducia 44. Vantaggio #9 Misurano la completezza 45. Vantaggio #10 Divertente 46. Strumenti per PHP 47. Installare PHPUnit pear channel-discover pear.phpunit.de pear channel-discover components.ez.no pear channel-discover pear.symfony-project.com pear install phpunit/PHPUnit 48. Convenzioni

  • I test per la classe Class vanno inseriti nella classe ClassTest.

49. Convenzioni

  • I test per la classe Class vanno inseriti nella classe ClassTest.

50. ClassTest estende PHPUnit_Framework_TestCase. 51. Convenzioni

  • I test per la classe Class vanno inseriti nella classe ClassTest.

52. ClassTest estende PHPUnit_Framework_TestCase. 53. I test sono metodi pubblici con nome test*. 54. Convenzioni

  • I test per la classe Class vanno inseriti nella classe ClassTest.

55. ClassTest estende PHPUnit_Framework_TestCase. 56. I test sono metodi pubblici con nome test*. 57. All'interno dei metodi di test, i metodi di asserzione comeassertEquals() vengono utilizzati per verificare che un certo valore corrisponda al valore atteso. 58. Assertions Le pi comuni AssertTrue/AssertFalse Check the input to verify it equals true/false AssertEquals Check the result against another input for a match AssertGreaterThan Check the result to see if its larger than a value AssertContains Check that the input contains a certain value AssertType Check that a variable is of a certain type AssertNull Check that a variable is null AssertFileExists Verify that a file exists AssertRegExp Check the input against a regular expression 59. Fixtures Una delle cose pi dispendiose nella scrittura dei test la parte relativa al codice per impostare l'ambiente e partire da unostato conosciutoe per poi tornarci alla fine del test. Lo stato conosciuto chiamatofixture . 60. setUp() Il metodosetUp()viene invocato prima dell'esecuzione del test. Permette impostare lo stato conosciuto necessario al test. 61. tearDown() Al termine dell'esecuzione del test viene invocato il metodotearDown() . Si occupa delle pulizie. 62. Doubles Sometimes it is just plain hard to test the system under test (SUT) because it depends on other components that cannot be used in the test environment. This could be because they aren't available, they will not return the results needed for the test or because executing them would have undesirable side effects. In other cases, our test strategy requires us to have more control or visibility of the internal behavior of the SUT. When we are writing a test in which we cannot (or chose not to) use a real depended-on component (DOC), we can replace it with a Test Double. The Test Double doesn't have to behave exactly like the real DOC; it merely has to provide the same API as the real one so that the SUT thinks it is the real one! --Gerard Meszaros 63. Stub Oggetto appositamente configurato per restituire valori predefiniti. Rimpiazza un oggetto reale dal quale dipende is SUT. Permette di avere il controllo sugli input indiretti del SUT. 64. Stub - esempio 65. Stub - esempio 66. Mock Oggetto appositamente configurato per verificare delle aspettative, come per esempio la chiamata di un metodo specifico. Punto di osservazione utilizzato per verificare gli output indiretti del SUT mentre in esecuzione. 67. Mock - esempio 69. Mock - esempio