Sessió C1: Susbcripcions i notificacions

Dimarts 15 i Dimecres 16 de Novembre

Objectius

• Evolucionar un sistema simple a "una mica complex", mantenint-lo "sota control"
• Decidir la navegabilitat més convenient entre associacions
• Dissenyar missatges amb molts nivells d'indireccions

Testejant amb stubs

En aquesta sessió, s'ens dona un component que simula una API d'un servidor de correu sortint. Fitxer: MailStub.hxx.

Resumint, un "stub" és un component de mentida que en substitueix un altre que no és convenient d'usar en els tests --per exemple, perquè és lent (imagineu-vos una BDs de veritat, o enviar un mail a cada test!) o perquè volem esperar a implementar un subsistema més endavant.

Patró singleton

Analitzeu el MailStub.hxx i fixeu-vos amb

• com implementem el patró Singleton en C++
• i com n'hem extret una classe base que podem reusar sempre que necessitem guardar un log de missatges.

Què fer quan tenim un segmentation fault (violació de segment) ?

Primer, mirar amb el debugger gdb dins quina funció ha petat. Noteu que us hem modificat el Makefile perquè conservi els simbols de debug.

	gdb ./TotsElsTests          executa els tests dins el debugger
	r                           fem un "run" fins la petada
	bt                          "back-trace" ens escriu la pila de crides a funcions
	q                           sortim
	

Si voleu usar un debuger gràfic per anar navegant pel codi i visualitzant variables, us recomanem el kdbg

A vegades el back-trace només ens dona una pista. Per acabar de caçar el bug podem usar xivatos: std::cout << "hem fet tal cosa\n"; Posarem sempre un xivato dins del mètode de test per indicar-nos a partir d'on llegir-los (sinó ens podem liar molt!).

Aquest mètode de caçar bugs pot semblar molt arcaic, però el desenvolupament basat en tests fa que "sota" cada cas de test tinguem un codi prou simple i el mètode sigui molt útil.

Tasques

1. Passar tots els tests funcionals (tots són obligatoris) fent desenvolupament dirigit pels tests (unitaris). Aquesta sessió també teniu una guia, però aquesta vegada més lliure.

Aquest és el diagrama de classes simplificat del sistema resultant



2. [Opcional] Passar la definició de tots els mètodes de totes les classes al seu corresponent .cxx.
   És una decisió de compromís (com moltes coses en programació): per un cantó, amb diversos .cxx es triga menys a re-compilar, per l'altre es tarda més a afegir/modificar mètodes. Però si el sistema es va fent complex arriba un punt en que és obligat separar-los. Apart, separant els headers són molt més llegibles.