Desenvolupament guiat per tests: Test-driven development (TDD)

debuggingsuckststingrocks

debuggingsuckststingrocks

Segons un estudi de Standish Group del 1994, només un 16,2% dels projectes informàtics té èxit. La resta té problemes o fracassen.  Un procés que per mi és clau és el desenvolupament guiat per tests. De fet, gràcies a una millor gestió de projectes, el 2004 aquesta xifra va millorar fins el 24% d’èxit.

Aquest article no és per tothom, està dirigit a programadors, tècnics, consultors i propietaris de llocs web.

No té res a veure amb els tests A/B o tests multivariants, sinó que té a veure amb la importància de la validació del funcionament. Validar el funcionament és la base de la piràmide d’optimització de la conversió.

Producte tancat sense canvis

Quan es fa un pressupost es pensa en el producte acabat i per tant es vol tenir la descripció final d’aquest per poder fixar el cost de desenvolupament en un preu tancat. Això funciona bé si no s’admet cap imprevist i no hi ha canvis durant el procés de desenvolupament. Amb l’enfocament en cascada, un cop enviat el disseny, tindràs el producte que vas dissenyar.  Habitualment en programació no és així i hi ha canvis durant el desenvolupament o al finalitzar aquest (en hardware és més difícil, oi?)

Per tenir en compte els canvis durant el desenvolupament, cal poder canviar el disseny inicial i saber modificar la programació en curs. L’enfocament “en cascada” no funciona bé i cal tenir una aproximació més “àgil”.

Depurar o validar el funcionament

Quan es programa, cal anar veient si el que fem està ben fet i per això a mesura que es va desenvolupant es provant si el que hem programat està bé. Si no coneixem el desenvolupament guiat per tests (TDD), el que es fa és programar i provar si funciona. Si no funciona, es depura fins que funcioni.

En TDD el que es fa primer és dissenyar el test, després es programa el codi per fer que el test estigui bé i al final es refà el codi per assegurar-nos que és més fàcil de llegir i que tot està bé.

tddLa definició del problema és part de la solució del problema

No t’ha passat mai que has hagut de depurar un codi una vegada i la pròxima vegada que falla et veus repetint algunes accions?

El test és part del desenvolupament final. El test ens ajudarà a validar que el que hem programat compleix amb el disseny. Les ganes d’acabar un desenvolupament fa que tinguem ganes de desenvolupar el codi directament quan encara no hem pensat com validarem que el que construïm estigui bé.

Cicle iteratiu de desenvolupament

Per utilitzar un enfocament àgil, trobo que és molt útil el concepte de iteració. El desenvolupament consisteix en una seria d’iteracions. Es tracta de que en una o poques setmanes es finalitzi la programació de parts del producte i així mostrar aquestes parts acabades al responsable final del producte abans d’acabar de desenvolupar-lo completament.

Al principi de cada iteració, cal saber quines parts del producte es faran i entendre les funcionalitats i escenaris d’us. Gràcies a dissenyar primer aquests tests, tindrem el coneixement de que el que hem programat compleix el que ens havíem proposat.

Experiència amb la validació del funcionament

Fer TDD amb phpunit o qualsevol eina de “tests unitaris” sembla ser molta feina, però es troba a faltar en tot projecte en el que no hi ha una manera de verificar el funcionament del les coses.

No n’hi ha prou en mirar si hi ha pàgines amb error. Val més tenir algun executable simple que no pas no tenir res. Per exemple un pàgina que executi totes les classes, mètodes  funcions, etc i s’asseguri que facin el que han de fer (puja/elimina fitxer, consultar/crear/modificar/eliminar, etc). I això no ho dic com a programador, ho dic com a tècnic de sistemes i com a responsable de llocs web.

Estaré encantat de llegir les vostres experiències en validació de funcionament o disseny guiat per tests en els comentaris d’aquest article.

Si en voleu saber més, us recomano el llibre Test Driven Development (By Example) de Kent Beck.