<div class="page"> <div class="cover text-center"> <img class="mx-auto" src=/itb/images/logo_mislata.png alt="logo"> # TDD - Test Driven Development <div class="text-end fit-content ms-auto my-3 mt-auto pt-3"> <p><strong>Autor:</strong> Joan Puigcerver Ibáñez</p> <p><strong>Correu electrònic:</strong> j.puigcerveribanez@edu.gva.es</p> <p><strong>Curs:</strong> 2024/2025</p> </div> <div> <p class="fw-bold mb-0">Llicència: BY-NC-SA</p> <p class="d-none d-md-block">(Reconeixement - No Comercial - Compartir Igual)</p> <a href="https://creativecommons.org/licenses/by-nc-sa/4.0/deed.ca" target="_blank"> <img class="mx-auto" src="/itb/images/license.png" alt="Licence"/> </a> </div><!--license--> </div><!--cover--> </div><!--page--> {:toc} ## Introducció Fins ara, normalment els projectes de programari s'han desenvolupat seguint una mètodologia de desenvolupament tradicional, com la cascada (waterfall), en la qual les fases de desenvolupament s'executen de forma seqüencial, sense possibilitat de tornar enrere i sense possibilitat de fer canvis en les fases anteriors. A més, no hi ha una retroalimentació continuada entre el client i el desenvolupador, i el client no veu el producte final fins que no s'ha acabat el projecte. Alguns d'aquests problemes es solucionen amb les metodologies àgils, com Scrum o Kanban, que es desenvolupen en xicotetes iteracions, amb una retroalimentació contínua entre el client i el desenvolupador, i amb la possibilitat de fer canvis en qualsevol moment del projecte. No obstant això, aquestes metodologies no solucionen un problema molt important: __com podem assegurar-nos que el nostre codi funciona correctament?__. En qualsevol de les metodologies anteriors es poden fer proves manualment, però això és molt costós i no és escalable, o fins i tot automatitzar les proves. No obstant això, normalment aquestes proves s'escriuen _a posteriori_, quan el codi ja està escrit, i per tant, no són tan efectives i no se'ls treu rendiment. Alguns problemes derivats d'aquesta situació són: - Els tests s'implementen i s'executen quan és massa tard perquè ens proporcionen informació útil, i per tant, es té la sensació que són una pèrdua de temps. - Sempre hi ha alguna cose més urgent que fer que escriure tests. - Es té por a refactoritzar el codi perquè no es té la seguretat de que no es trencarà alguna cosa. _If it works, don't touch it_. - El cost de manteniment és molt elevat. - La documentació mai està actualitzada. - El desplegament o la posada en producció és no està controlada i el resultat és imprevisible. - L'equip de desenvolupament passa molt de temps intentant averiguar per què el que fa un mètode o una classe. El __Desenvolupament Guiat per Proves, o Test-Driven Development (TDD)__ no soluciona màgicament tots aquests problemes, però ens proporciona una manera de treballar que ens permet evitar-los. ## Què és el TDD? El TDD una metodologia de desenvolupament de programari en la qual __les proves unitàries es redacten abans que la implementació del codi__. Segueix un cicle de desenvolupament curt i repetitiu, que es pot resumir en tres passos: - __RED__: Escriure una prova unitària que falla. - __GREEN__: Escriure el codi __mínim__ necessari perquè la prova passe. - __REFACTOR__: Refactoritzar el codi perquè siga més llegible, mantenible i eficient. #2.1[Cicle del Desenvolupament Guiat per Proves](/itb/DAM-ED/UD5/img/tdd.webp){height=300px} Com les proves s'escriuen abans que el codi, es suposa que la prova fallarà inicialment. Si la prova no falla, és que la prova no és bona, ja que descriu un comportament que ja existeix o que s'ha implementat incorrectament i, per tant, auqestes les proves s'haurien d'eliminar o refactoritzar. ## Recursos addicionals - https://www.baeldung.com/java-unit-testing-best-practices - https://www.youtube.com/watch?v=_t9l2TwGioc ## Bibliografia - Farcic, Viktor, and Alex Garcia. _Test-Driven Java Development: Invoke TDD Principles for End-to-End Application Development with Java._ Packt Publishing, 2015.