Com escriure els teus test unitaris
From Es1
Sovint s'explica el desenvolupament dirigit per tests (TDD) amb la metàfora de l'escalada. Mireu-vos la.
A partir de la pràctica B2 heu d'escriure els vostres propis tests unitaris. Nosaltres us donarem els funcionals, però, els funcionals són l'objectiu final de l'escalada. Fins que arribeu a un test funcional heu de clavar un munt de claus en forma de test unitaris que us asseguraran la pujada. Aquests claus normalment involucren exercitar les classes de domini per sota de la facade, de tal forma que la facade només faci una crida.
Contents |
Com decidir quin és el següent pas a fer?
El següent pas a fer ha de ser el més directe i simple que pogueu fer cap a l'objectiu final. Penseu que ha de ser tan tonto com per poder fer un verd rapid (amb trampes o no). Com a regla de polze: si passar a verd triga més de 2 minuts l'heu posat massa lluny.
Quina estructura té un test unitari?
Els tests unitaris tenen tres parts lògiques:
- Set Up: Poso el sistema en les condicions de test
- Exercise: Faig l'acció que vull testejar
- Assert: Comprovo que ha funcionant com esperava
- Tear Down: Deixo el sistema en les condicions inicials perque el següent test pugui començar bé
Si pensem en el sistema com un gran diagrama d'estats:
- el setup es moure el sistema de l'estat inicial a l'estat que representa les condicions de test
- el exercise es disparar una transició
- l'assert es comprovar que hem anat a parar a l'estat correcte
- el teardown es tornar a l'estat inicial
void testDesafina_perd10Punts()
{
// Setup
UnArtista artista;
artista.afegeixPunts(39);
// Exercise
artista.desafina();
// Assert
ASSERT_EQUALS(29, artista.punts())
// Tear Down (la pila ja elimina l'artista creat)
}
Com plantejo els tests?
Us recomanem que els test no els plantejeu en ordre linial setup-exercise-assert-teardown. Anireu més a ritme si ho feu desordenat així:
- Assert: em plantejo quin es l'objectiu a comprovar del test
- Exercise: em plantejo quina es l'acció a provar
- Setup: em plantejo com arribar a les condicions de test
- Teardown: em plantejo com desfer tot el que he fet
Cal dir que no sempre hi haura codi a cada part.
Pero si cal plantejar-se-les totes.
Com faig l'assert
Normalment es fa servir el valor de retorn d'algun mètode de l'objecte. Aquest mètode va bé que sigui constant, és a dir, que no modifiqui l'estat de l'objecte:
class Artista
{
...
int punts() const
{
return _punts;
}
...
}
Hi ha altres casos no normals que us expliquem a continuació.
Com testejo una condició d'error?
Sovint el que volem testejar es que, si fem quelcom en un punt concret, el sistema ha de queixar-se (llençar una excepció). Als tests funcionals hi ha un exemple de com fer aquest tipus de test.
void testAfegirCanso_quanMasterNoExisteixFalla()
{
SingalongOnline negoci;
negoci.afegeixArtista("Un artista",false);
try
{
negoci.afegeixCanso("Un artista", "Una canso", "unFitxer.wav");
FALLA("Hauria de haber llençat una excepcio");
}
catch(std::exception & e)
{
ASSERT_EQUALS("L'arxiu master no existex",e.what());
}
}
- Si no llença l'excepció, el FALLA s'executarà.
- Si llença una excepció no esperada, no l'agafem i el test falla també
- Un cop agafada l'excepció voldrem que el missatge sigui el que volem
Que són els mètodes setUp i tearDown?
Sovint tots els casos de test d'una fixture s'executen sota unes condicions inicials molt semblants. No és gaire pràctic anar repetint el codi de setup i teardown a cada mètode. Per això, els frameworks de testing et permeten definir uns mètodes setUp i tearDown que es criden abans i després de cada métode de test. D'aquesta manera podem fer les inicialitzacions i netejes comunes.
Per poder comunicar el setup, el tearDown i els mètodes de test farem servir attributs de la fixture.
