[TDD-sp] Diseño de modelo de datos y TDD
Joaquín Engelmo Moriche
Buenas a todos,
más de una vez me ha asaltado una duda, una laguna que tengo en el uso de
TDD para el desarrollo de una aplicación y, hasta ahora que voy a
enfrentarme con ello, no he decidido preguntar por aquí. Espero que los
señores con más experiencia y conocimiento que yo me iluminen en este
sendero hacía el "nirvana" del código (madre mía, como desvarío...)
Os muestro el escenario:
Quiero empezar una aplicación desde cero, concretamente en Grails, y para
ello aplicar TDD (es un proyecto propio, puedo hacer lo que me venga en gana
:D). La duda que me llena es ¿Diseño del modelo de datos vs Modelo de datos
emergente? ¿O ambos cada uno a su nivel? En algún correo leí a JMBeas
(corrígeme si me equivoco) quejarse sobre "tener que definir el modelo de
datos siempre antes". Tengo las historias de usuario definidas, me falta
dividirlas en pomodoros y asignarles prioridad pero esa es otra historia.
Las opciones que me planteo:
- Diseño el modelo de datos como toda la vida: lápiz y papel (hablo de
entidad/relación) ... luego TDD para la lógica de las funcionalidades
- Diseño mínimo del modelo de datos (quizás entidades obvias) y, a partir de
eso, modelo de datos emergente a partir de TDD
- Nada de diseño mínimo... todo a partir de TDD
Yo opto por la opción del medio. Mi idea es (por favor, criticad todo lo
criticable):
- Un modelo de datos mínimo, como las entidades del sistema (modelo del
dominio o algo así le llaman)
- Ponerme con TDD. Esto sería pruebas unitarias donde crear entidades e
irles asignando atributos que no tendría, prueba falla, se crean, prueba
pasa, se refactoriza. Si, por ejemplo, los atributos los pide el constructor
estamos hablando de atributos "not-null", si no son obligados, serían solo
"seteables", entonces pueden ser nulos. Las relaciones entre entidades
igual, se van creando clases, asignándolas entre ellas según las
responsabilidades y/o información que manejen y va saliendo el modelo.
- Completar con pruebas de las funcionalidades.
¿Cuál es vuestra experiencia? ¿Cómo os enfrentáis a esto? La verdad que,
esta tarde recordaba, esta es una de las dudas que el libro de Carlos no
consiguió resolverme (crítica constructiva), seguramente no he sabido verlo.
Bueno, espero vuestras respuestas :D Gracias de antemano!
Israel Alcázar
Israel Alcázar Rodríguez
israel...@gmail.com
http://www.farmerdev.com
http://www.twitter.com/ialcazar
--
Has recibido este mensaje porque estás suscrito al grupo "TDDev" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a tdde...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a tddev-sp+u...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/tddev-sp?hl=es.
Carlos Ble
Yo no suelo crear entidades hasta que no me van haciendo falta. Si es puro CRUD, no hago TDD, voy haciendo codigo y tests de integracion a posteriori; justo despues de escribir un trozo de codigo, su test. Si no es simple CRUD, hago TDD y voy creando lo que necesito por el camino. Tambien partiendo del criterio de aceptacion hacia abajo. Es decir, para no perder el objetivo de lo que quiero hacer, mirando demasiado los detalles, parto de las metas de aceptacion y voy desgranando.
Estoy de acuerdo con muchas cosas de Domain Driven Design, pero la gran mayoria de las cosas que dice, no las aplico a priori sino mediante refactorings, o mediante tests. Ya sabes, escribo primero el test cuando hago TDD, pero ya intentando pedirle al SUT la API que me conviene, atendiendo a criterios como los que defiende el autor del libro de DDD.
Afortunadamente todo esto sigue siendo bastante artesanal, creo que no hay reglas fijas sino que depende del problema. Es cojonudo porque asi nunca dejamos de aprender. Igual dentro de unos años te digo otra cosa :-)
Carlos Ble
www.MavenCharts.com
www.iExpertos.com
www.carlosble.com
Alfredo Casado
Luismi Cavallé
mínimas asunciones y evitando establecer ningún prejuicio. Empezar con
el lienzo en blanco y la mente abierta, dispuesto a implementar lo
mínimo que cada test me pida. Y de fuera a dentro (outside-in), es
decir, dirigido por un test de aceptación (o integración o como lo
quieras llamar) de alto nivel, basado en una historia de usuario.
Desde la superficie hasta las capas inferiores de tu arquitectura,
haciendo TDD de unidad de lo que surja por el camino.
Aunque sea sólo como ejercicio, me parece superútil probar esta
estrategia de manera lo más radical posible. En ocasiones, acabas
sorprendido del diseño al que acabas llegando, o de como un problema
que no parecía sencillo de resolver casi se ha resuelto solo (es mucho
más duro tener que resolver el problema completo en la cabeza, que
sólo tener que hacer pasar el siguiente test). Es la mejor manera que
conozco para evitar la sobreingeniería y asegurar que el 100% del
código escrito sirve para satisfacer una necesidad de negocio
especificada en una historia (menos código es siempre mejor)
Probablemente, desde un punto de vista pragmático, hacerse un
diagramilla de objetos al principio del proyecto puede parecer que no
hace ningún daño y puede servir para ponerse en contexto, en
situación. Siempre y cuando luego se tire a la basura y no se
implemente nada que no pida un test, claro. Lo que hay que tener en
cuenta es que ese primer diagrama se va a convertir, lo queramos o no,
en punto de referencia respecto al resto de decisiones que tomemos
después. Consciente o inconscientemente, vamos a tender hacia aquello
que pintamos cuando menos sabíamos del proyecto.
Además, si utilizas un framework como Grails ya tienes un montón de
asunciones tomadas, una arquitectura por defecto muy determinada y un
montón de convenciones. No creo que haga falta diseñarse el modelo de
datos para ponerse en situación.
-- Luismi
P.D. He entrado al trapo directamente y me saltado las presentaciones.
Hola a todos!
On Aug 23, 9:15 pm, Joaquín Engelmo Moriche <kinisoftw...@gmail.com>
wrote:
Jorge Uriarte Aretxaga
vez, yo creo que es muy útil saber qué camino te propones tomar, o al
menos en qué dirección.
En ese sentido, mi aproximación a un sistema *nuevo* suele ser hacer
un boceto del modelo estático del sistema (sea este objetos, tablas,
cajitas, realmente no me importa demasiado), y otro boceto del
dinámico (servicios, interacciones, etc...)
Normalmente esto lo hago bien en pizarra, bien en cualquier
herramienta no-formal, y me ayuda a:
- Comprender mejor el alcance
- Plantear una base de discusión para todo el equipo
Riesgo:
- El equipo puede interpretar *tal cual* ese boceto como *el diseño a
programar*, en lugar de una abstracción técnica de una posible
aproximación al problema. Nuestros equipos ya saben que eso es *un
mapa en una servilleta*, algo para pensar y discutir, no algo a
*obedecer*.
- Se puede entrar en demasiado detalle. En ese sentido limitar ese
boceto a unas pocas horas de trabajo, y la experiencia, ayudan a
decidir en qué momento ya no resulta util seguir trabajándolo.
Ventajas:
- Unifica visiones, levanta en seguida diferentes comprensiones del
espacio del problema
- Sirve de modelo formal, menos dado a errores que la descripción
textual, para la comunicación inicial y la sincronización del equipo.
- Anticipa peculiaridades que pueden determinar la elección de una
tecnología/framework/librería.
Dependiendo de la plataforma, puede tener sentido aquí hacer una
primera versión esquemática del modelo de datos (en grails por ejemplo
hacer esto con entidades vacías relacionadas es muy sencillo), pero no
es obligatorio. El riesgo es que parezca que lo que está hecho tiene
que *sobrevivir* por narices y su mera existencia imponga la decisión.
Pero como eso no debería pasar tampoco para artefactos desarrollados
más adelante, pues...
A partir de aquí, y con la certeza de que nada está escrito en piedra,
y que realmente todo está por descubrir, el enfoque TDD me parece
óptimo (y *no* lo hacemos lo suficiente, tenemos que mejorar mucho en
ese aspecto).
En resumen; yo necesito algo de visión y reflexión al principio, y veo
imprescindible jugar con los *grises*; ni intentar cerrar todos los
detalles ni saltar al vacío sin mirar. Sobre todo porque la *entrada*
a ese proceso, la propia definición del backlog y las especificaciones
estén en la forma que estén, tampoco suelen estar cerradas ni
ordenadas, y también pasan por ese proceso de reflexión. Si se da el
caso de que el backlog llegue trabajadito y pulido al equipo técnico
(nunca es mi caso), supongo que el enfoque es más viable.
Abrazos!
_
Jorge Uriarte Aretxaga
http://www.gailen.es
http://www.linkedin.com/in/jorgeuriarte
2010/8/23 Alfredo Casado <casado....@gmail.com>:
