El blog de Trespams

[ x ]

Faig servir les cookies de Google Analytics per al control de visites i estadístiques..
És una pardalada, però la llei diu que us he d'avisar, ja veus. Així que si visitau aquest blog donau-vos per informats o sortiu ara mateix i netejau les cookies del vostre navegador. Si continuau llegint, suposaré que ja us està bé. Si vols saber com llevar les cookies del teu navegador: aquí ho pots trobar

Unit tests

Supòs que no he de convèncer ningú de les bondats dels tests unitaris a l'hora de desenvolupar.

Encara que no arribem als extrems que proposa la gent que fa "test driven development" tenir tests ajuda a l'hora de provar les aplicacions:

  • Queda constància del que s'ha provat
  • Les proves són repetibles
  • Es poden anar afegint noves proves quan es detecten noves situacions i/o errors.
  • Ens ajuden a la refactorització, ja que ens ajuden a comprovar que la refectorització no ha variat el funcionament del programa.

El clàssic en test unitàris per Python és PyUnit que segueix una aproximació diguem-ne ortodoxa, és a dir, basada en crear una classe que extén TestCase i a partir d'aquí anar agrupar els tests en el que s'anomena una TestSuite.

Una altra aproximació ben diferent és la de doctest, aquí el que tenim és que s'escriu el codi de testeig i la serva sortida dins de la mateixa aplicació, no hi ha API però sovint pot resultar un tant confús.

Finalment tentim un nouvingut (relativament, que ja té uns anyets) el py.test, que ve avalat per la gent de PyPy i que va ser creat per a testejar el desenvolupament de l'intèrpret de Python fet en Python.

En Grig Gheorghiu's té un conjunt de tres articles comparant unittest, doctest i py.test, encara que són un poc antics, en temps Internet, crec que ajuden molt a veure les principals mancances i avantatges de cada un.

Per suposat, hi ha molts més a sistemes de testeig, podeu trobar-ne una recopilació a Python Testing Tools Taxonomy

He estat gairebé una setmana desenvolupant i fent tests amb py.test, i he de dir que m'ha agradat, és molt més còmode de fer anar que cap dels altres. Basta que creis un mètode que comenci amb test_ o acabi en _test i ja ho tenim llest per ser provat, que passi el test o no sols es cosa de que hi hagi un asssert que retorni vertader si ha passat un testo o fals si no l'ha pasat.

Una de les característiques que m'han agradat més és la possibilitat de desactiva ràpidament un test amb disabled = True on el valor es pot substituir per una condició, amb la qual cosa podríem fer que un test s'executàs o no en funció de l'avaluació d'una condició, per exemple, si detectam que estam a l'entorn de producció no borrar la base de dades!

I també he trobat molt còmode l'opció de poder establir condicions d'inici i acabament per tot un mòdul, això m'ha permés per exemple, obrir una sessió i mantenir la connexió i el identificador de sessió per a tots els tests, tancant la sessió sols quan tots els tests ja han acabat.

La part que m'ha xocat és la manera de testejar les excepcion, ho fan amb

 py.test.raises(Exception, func, *args, **kwargs)
 py.test.raises(Exception, "func(*args, **kwargs)")

És a dir, s'ha d'importar el mòdul py i cridar a py.test.raises, després posarem l'excepció que volem tractar, la funció que s'ha de testejar i que genera aquesta expepció i seguidament els paràmetres que té la funció.

Crec que això ha estat la única cosa més complicada d'aprendre. La resta és tot ben natural.

Me falta provar la part de distribució de tests, però per ara crec que va camí de convertir-se en la meva eina de testeig Python de referència, a l'espera, això sí, de veure com ho puc integrar amb Hudson.

blog comments powered by Disqus
<<<<<<< main/templates/puput/base.html ======= >>>>>>> main/templates/puput/base.html