Presentacion y consulta

[Diego Spinedi]

Buenos dias, mi nombre es Diego Spinedi y estoy dando mis primeros pasos en TDD. Me estoy valiendo de mucha literatura, entre ellas, el libro de Carlos Ble. 

Todas mis experiencias en TDD (cursos, seminarios) no he visto ABM´s (simpre hice katas) y obviamente me remito a ustedes, ya que tienen una elevada experiencia en este tema para que me ayuden a ver como se puede encarar un ABM. 

En este caso nos dieron en nuestra empresa la posibilidad de encarar nuestro primer proyecto con TDD con el alta de familiares de un afiliado. En principio algo sencillo, con algunas reglas fuertes, pero nada del otro mundo. Y la duda que se me planteo es como se arma una prueba que deberia "chequear" contra una base de datos. Si bien se que se usan Mocks mi consulta es ....¿que se prueba cuando quiero grabar un nuevo familair en mi base de familiares? ¿se prueban cada uno de los datos? ¿se prueba un "true" de que hay un elemento en la coleccion?-....como veran...sepan disculpar pero estoy dando mis primeros pasos y mi pregunta puede ser algo "básica".

Saludos a todos y gracias de antemano!

Diego Spinedi

[Carlos Peix]

Hola Diego,

Que bueno que la empresa les de la posibilidad de utilizar TDD.

Creo ques importante aclarar que TDD es una técnica de diseño y construcción de software. Usualmente, los ABMs no tienen un componente de diseño complejo, por lo tanto, es muy probable que no encuentres una aplicación clara.

Por otro lado, considero que TDD es un concepto amplio que sugiere que el diseño y la construcción estan dirigidos o guiados por pruebas o verificaciones. Luego, que tipo de pruebas utilices y como las razones o pienses o elabores, te lleva a variantes.

Si utilizas pruebas de aceptación, seguramente estarás mas cerca de ATDD, si, ademas, te basas en ejemplos concretos surgidos de la funcionalidad a construir (como debería hacerse SIEMPRE), estarás mas cerca de BDD, si utilizas pruebas unitarias y pruebas a tus objetos desconectados del mundo exterior, entonces será TDD.

Yo, en el caso de ABMs, optaría por pruebas de integración justo por debajo de la UI (sin intervención de la UI), llegando a la base de datos, es decir, sin test doubles.

Luego, si ves que algún objeto, por ejemplo, un validador, tendría lógica relevante, lo escribis con TDD (pruebas unitarias).

Todas las pruebas que generes, por supuesto, deberías correras en un simple servidor de integración continua y con esas pruebas de regresión ejecutándose en cada commit o push, probarás a la empresa que no se equivocó al permitirles usar TDD.

Un saludo

----------------------------------
Carlos Peix

--
Has recibido este mensaje porque estás suscrito al grupo "TDDev" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a tddev-sp+u...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a tdde...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/tddev-sp.
Para acceder a más opciones, visita https://groups.google.com/d/optout.