Cómo planificar e incluir TDD en un Proyecto

[Matias Mascazzini]

Hola a todos,

estoy armando la planificación para un proyecto en el cual pienso incluir TDD para el desarrollo del algunos módulos, y desarrollo sin TDD en otros. Con el objetivo de comparar las experiencias.

¿Qué actividades hay que resalizar en TDD y como las planificarían?

Más o menos lo que tengo es:

2.1 Generar ERS

2.2 Desarrollo Modulo A: visión tradicional.

- Confeccionar casos de uso, diagramas de actividad, diagramas de secuencia.

- Prototipar interfaces graficas de usuario.

- Codificar modulo A.

- Codificar pruebas unitarias modulo A.

- Ejecutar pruebas, meditar tasa de fallo y errores.

2.3 Desarrollo Modulo B: visión TDD.

- Confeccionar historias de usuario sobre requisitos para modulo B.

- Codificar modulo B siguiendo TDD.

- Ejecutar pruebas, medir tasa de fallo y errores.

2.4 Conclusiones:

- Comparar experiencias de desarrollo (variables cualitativas y cuantitativas)

Desde ya muchas gracias por los consejos y sugerencias.

Saludos
Matías Mascazzini

Corrientes, Argentina

Me encuentras en:
LinkedIn: http://ar.linkedin.com/in/matiasmasca/es
Twitter: @matiasmasca
ComunidadTIC: @matiasmasca
---------
Le recomiendo visitar: www.ComunidadTIC.com.ar
"¿Eres Informático?"

[Angel Java Lopez]

Pregunta rapida: que es generar ERS?

2013/5/2 Matias Mascazzini <matia...@gmail.com>

--
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 correos electrónicos, envía un correo electrónico a tddev-sp+u...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a tdde...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/tddev-sp?hl=es.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[Matias Mascazzini]

Un documento de Especificaciones de Requisitos Software ANSI/IEEE 830, 1998. , un tanto anticuado, pero cómo ya lo tengo hecho lo quiero vincular con TDD.

Saludos
Matías Mascazzini

Corrientes, Argentina

Me encuentras en:
LinkedIn: http://ar.linkedin.com/in/matiasmasca/es
Twitter: @matiasmasca
ComunidadTIC: @matiasmasca
---------
Le recomiendo visitar: www.ComunidadTIC.com.ar
"¿Eres Informático?"

2013/5/2 Angel Java Lopez <ajlop...@gmail.com>

[Matías Mascazzini (Corrientes)]

Por ahora lo qué más me interesa es saber como planifican las actividades sin van a usar TDD, desde un punto de vista de la administración de proyectos. O sino que actividades realizan y el orden de las mismas.

Agradezco sus comentarios, todavía no tengo experiencia pro con TDD.

[Carlos Ble]

Hola,

Planificas los bucles y las funciones en el plan de proyecto?

Para mi TDD es la forma en que escribo el codigo y por eso no necesito una planificacion diferente, simplemente hago TDD para escribir codigo de la mejor forma posible :-)

Por otro lado, si el equipo no tiene experiencia con TDD, lo que hay que hacer es formarse, no meterse en el proyecto a aprenderlo de golpe.

No se si te referias a esto.

Saludos :-)

2013/5/2 Matías Mascazzini (Corrientes) <matia...@gmail.com>

--

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 correos electrónicos, envía un correo electrónico a tddev-sp+u...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a tdde...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/tddev-sp?hl=es.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--
Carlos Ble

www.CarlosBle.com - @carlosble 

Check out my book on TDD: www.dirigidoPorTests.com/el-libro

Try my latest app for team productivity: www.liveTeamApp.com

Need test doubles for python?: www.pyDoubles.org

[Angel Java Lopez]

Bien, supongo que estamos en un proyecto agil.

Voy a exponer mi experiencia, con algo simil Scrum. Sea que el cliente quiere un tablero de control, por la web. O sea, varias paginas para ver el estado de la empresa, con filtros entre fecha, etc, etc.

Se plantea con el product owner cual es el caso de uso mas importante.

Se ve con el equipo que tareas podemos implementar del caso de uso.

Por ejemplo, segun el product owner, lo que mas se necesita ver es un grafico con los ingresos vs los egresos, por area (invento el caso). Vemos con el equipo que no podemos hacer todo el caso de uso en la iteracion semanal. Pero podemos prometer entregar un grafico, del mes actual.

No tuvo nada que ver TDD todavia.

TDD nos sirve entonces, para el desarrollo dia a dia. Generalmente me manejo con algun MVC, asi que planteamos el controler y la action que nos devuelva los datos del mes actual. Si es una de las primeras iteraciones, ni siquiera tenemos base de datos, solamente un modelo en memoria. Escribimos el action USANDO TDD, ACA ES DONDE APARECE.

Luego, o en simultaneo, hacemos la vista. Tal vez un spike para probar algo de JavaScript y graficos, para elegir una libreria inicial para mostrar un grafico de barras, o lo que nos hayan pedido. Trato que el equipo muestre algo simple.

Probamos todo junto, ahora que ya tenemos el action con TDD, y la vista. Mejoramos la vista, generalmente sin necesidad de recompilar el codigo del servidor

Tenemos lista la demo.

Proxima iteracion:

- La vista permite cambiar el mes

- O pasamos los datos a la vista, no en el modelo que entrega la action, sino como JSON, de nuevo, la nueva action probada con TDD

....

Iteracion 5

- Ya tenemos varios graficos. Fuimos refactorizando los controller/action, para que los datos que vamos descubriendo que se necesitan en varias partes, sean servidos por servicios (simples metodos en memoria). El modelo de dominio va tomando forma.

En alguna iteracion, o de a poco (una entidad por vez), vamos pasando el modelo de dominio, de memoria a alguna persistencia, probablemente una base de datos. Todos los tests nos sirven para esos pasos.

...

etc, etc...

Pero al final, para planear, lo importante, mas que TDD, es la evaluacion agil: que prometemos, y que sea importante para el cliente. Por eso, en la primera iteracion, mas que un modelo de datos, o la seguridad y login, vamos por un caso de uso visible e importante.

Se entendio?

Nos leemos!

Angel "Java" Lopez

@ajlopez

2013/5/2 Matías Mascazzini (Corrientes) <matia...@gmail.com>

Por ahora lo qué más me interesa es saber como planifican las actividades sin van a usar TDD, desde un punto de vista de la administración de proyectos. O sino que actividades realizan y el orden de las mismas.

--

[Matias Mascazzini]

Gracias Angel, leyendo y reflexionando sobre lo que escribiste.

Saludos
Matías Mascazzini

Corrientes, Argentina

Me encuentras en:
LinkedIn: http://ar.linkedin.com/in/matiasmasca/es
Twitter: @matiasmasca
ComunidadTIC: @matiasmasca
---------
Le recomiendo visitar: www.ComunidadTIC.com.ar
"¿Eres Informático?"

2013/5/2 Angel Java Lopez <ajlop...@gmail.com>

Bien, supongo que estamos en un proyecto agil.

[Pablo Carranza]

Hola Matías, desde mi punto de vista estás encarando el TDD partiendo desde la posición de cascada lo cual hace que en realidad no encaje del todo. Sobre todo en lo que planteas como punto final de cada uno de los grupos: - Ejecutar pruebas, meditar tasa de fallo y errores.

En TDD esto no es así, porque en resumen, estás ejecutando los tests TODO EL TIEMPO, es decir, programas primero un test, muy simple, que falla porque el código aún no está implementado, y luego programas el código que hace pasar el test, e iteras, una vez, dos, mil, hasta que completas la funcionalidad requerida.

Esto lo puedes hacer utilizando requisitos, o cualquier otro sistema que te apetezca, siempre y cuando tengas claro cual es la funcionalidad que tienes que dar (sea por una historia de usuario, caso de uso, requisito, etc).

Lo que denominas como punto 2.3.c y 2.4 en si no es realizable. Es decir, el hecho de ejecutar una batería de tests en un desarrollo planteado con cascada (punto 2.2.f) donde los tests se programan posteriormente al código. Si estos tests son ejecutados por primera vez, lo más probable es que la gran mayoría falle, o en su defecto que no prueben las cosas correctamente, o que el desarrollo de los test sea muy difícil porque el código que preparasteis no sea realmente "testeable", por lo que tendréis que gastar mucho tiempo en refactorizar estos tests bien para que valgan de algo o para que simplemente funcionen.

En cambio los tests que se hacen junto con el código están siendo probados constantemente, por lo que funcionarán mucho mejor, y probablemente sean mucho más útiles y modifiquen tu forma de codificar simplemente para ser capaz de probar las cosas.

Finalmente, hacer una comparación cuantitativa de una metodología y otra es difícil, e incluso diría que inútil. En mi opinión TDD aporta la posibilidad de refactorizar en cualquier momento, sabiendo que por mucho que cambie el código los tests pasan, por lo que no he roto nada, esto lo que aporta es mantenibilidad, además de seguridad y confianza (ni que decir de claridad en el código, documentación desde el test, etc, etc), lo cual no es tan fácil de medir y cuantificar.

Si insistes en medir y cuantificar siempre puedes utilizar cobertura de código para "ver" algo, aunque esto no sea determinante.

En fin, creo que el asunto lo estás encarando desde el punto de vista industrial, cuando en realidad vas a realizar una actividad artística/artesana, no son actividades comparables.

Saludos

2013/5/3 Matias Mascazzini <matia...@gmail.com>

--
Pablo Carranza

[Antonio Martinez]

Coincido con los comentarios en que creo que estás enfocando TDD como una alternativa a la gestión de proyecto en cascada y no es así. Por ejemplo incluyes en el enfoque TDD las historias de usuario. 

También te digo que hacer las pruebas después de codificar todo, no tiene mucho sentido, va a ser muy costoso y seguramente serán test enfocados en el código y no enfocados en los requisitos/historias/valor.

Como recursos para aprender TDD te aconsejo los que yo he usado:
- El libro de Carlos Blé. http://www.dirigidoportests.com/el-libro

- El blog de Javier Gutierrez http://iwt2-javierj.tumblr.com/

Solo un apunte, aunque se considere a TDD una actividad artesanal en contraposición a un enfoque industrial, eso no quita utilidad, sencillez, robustez y aplicabilidad al TDD. A título personal, al cambiar a TDD consigo, código más legible, más robusto, mucho más fácil de cambiar inclusive de borrar, mucho más cercano a los requisitos, más fácil de mantener, etc. Lo he utilizado en varios proyectos desde simples katas a proyectos más grandes y es perfecto para entornos industriales.

[Matias Mascazzini]

Gracias por sus respuestas Pablo y Antonio. Obviamente me falta más entendimiento sobre TDD o sus practicas asociadas, o no debo estar expresándome bien. Hasta ahora he realizado un par de Katas y ejercicios, seguido el libro de Carlos, pero no he trabajado de esta forma profesionalmente.

En este punto necesito vincular las practicas asociadas a TDD con una planificación de proyectos (listado de actividades) para el punto donde pretendo aplicar TDD; estoy pensando que debería de incluir tareas propias ATDD o BDD en este punto. Con respecto a esto lo que puedo sacar en limpio, de lo dicho por Pablo, es que como planificación el enfoque esta en la funcionalidad. Lo tengo que combinar también con lo que sugirió Ángel.

Desde el punto de vista de la comparación con otras formas de trabajar, va a ser un desafío llegar a una conclusión que no este sesgada, pero necesito hacerlo. Pero son justamente a esas conclusiones que citas Pablo que seguramente terminaré llegando con este experimento.

Saludos
Matías

2013/5/3 Antonio Martinez <amal...@gmail.com>

[JJG]

Antonio, muchísimas gracias por la cita por la parte que me toca. Si me lo permitís, añado un enlace a un libro de TDD práctico que estamos escribiendo y del que ya tenéis tres capítulo para consultar:

http://es.scribd.com/doc/137055522/Desarrollo-Dirigido-por-Pruebas-Practico

Matías, mucha suerte con tu proyecto.