Hola Diego, Nosotros corremos la suite de test contra el repositorio real ( la base de datos ) con mucho menos frecuencia que sobre el repositorio de test ( en memoria ). Esto se debe a varios motivos: a) los tests corren mucho (muchisimo) mas rapido, si el test corre rapido, se corre mas seguido, importantisimo; b) ante cambios en el modelo, la inercia del repositorio en memoria es mucho menor, es decir, no hay que hacer cambios de esquema en la base de datos (esto tambien es importante para controlar la pereza del desarrollador); c) es bastante molesto administrar la base de datos de testeo, al menos en mi experiencia, asi que es mejor hacerlo automatizadamente y durante el build automatizado, como comento Luis. d) Al principio del desarrollo no tenemos la base de datos para hacer mas agil el desarrollo del modelo (esto esta relacionado con el punto b) e) Tenes que tener una BD exclusiva por desarrollador (para los unit tests), de lo contrario, tarde o temprano tenes colisiones. Contestando tus preguntas: 1) No es necesario tener una BD real para realizar unit tests, si es necesaria para correr los unit tests contra el repositorio real y, desde ya, para correr la aplicacion, aunque yo siempre muestro la aplicacion, durante las primeras iteraciones, corriendo contra el repositorio en memoria. El motivo es el de siempre, es mas agil, mas facil. 2) Primero deberia decir que nosotros testeamos el modelo y, en general, no me encuentro con mucha operacion CRUD completa. Pero si lo hiciera, hay dos alternativas: a) esteas cada operacion CRUD por separado, para lo cual necesitas la base de datos inicializada con los registros correctos ( es mas dificil el setup de la base de testeo ), b) testeas todas las operaciones en el mismo test, por lo tanto creas el registro, lo lees, lo modificas y lo borras. 3) Hay un nuevo atributo TearUp? :). Podes correrlo a mano ( o como parte del build automatizado ) o en el SetUp y el TearDown, depende de como trabajes segun mi respuesta del punto 3. Yo prefiero el primero porque el segundo te obliga a hacer malabarismos para que no sea lentiiiisimo. 4) Sin duda la DB debe ser exclusiva por desarrollador. Hay una buena cobertura de este tema en el libro de Jimmy Nilsson. Carlos
_____ From: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] On Behalf Of Diego Jancic Sent: Jueves, 07 de Diciembre de 2006 12:18 a.m. To: patrones List Member Subject: !-> [patrones] Testing Hola gente hoy vengo con algunas preguntitas sobre TDD, mas practicas de lo normal los temas son los siguientes: 1) Es necesario tener una DB real (me refiero a que no sea mockeada) por desarrollador o usan todo el tiempo la mockeada dicho de otra forma, cuantas personas y cada cuanto ejecutan los tests en una DB no mockeada?? 2) Como se testea un select/update o delete por ID en una DB real?? Es decir, después de ejecutar el script para configurar el estado inicial de la DB tienen que cambiar alguna propiedad constante en los tests, no?? Tambien el Test de borrar podria crear el registro, pero no me gusta mucho ustedes que hacen? 3) El script de configuración de la DB, lo ejecutan en el TearUp o a mano?? Cada uno tiene sus ventajas 4) Según algunos articulos, es necesario un DB por desarrollador, ademas de la compartida pero es real esto? Con la mockeada no es suficiente? Veran que todas mis preguntas son sobre como testear una DB no mockeada Si alguno tiene un ejemplo o articulo bueno tambien lo voy a agradecer Saludos a todos!, Diego
