Para hacer los testings, podes crear la base con ExportSchema, ejecutar los
test.. y dropearla...
(Obviamente en un esquema preparado para testing)
con esto, te aseguras, de que los datos no te cambien y los testing empiecen a
fallar por cuestiones de datos
Se entiende?
--------------------------------------------------------------------------------
rdi2k | Ezequiel Jadib | MSN: [EMAIL PROTECTED] | Blog: ejadib.wordpress.com
----- Original Message -----
From: Diego Jancic
To: patrones List Member
Sent: Thursday, December 07, 2006 10:02 AM
Subject: [patrones] Testing
Porque?? El ExportSchema crea las tablas nada mas... de que me puede
servir??? hay algo del ES que no sepa?
On 12/7/06, Ezequiel Jadib <[EMAIL PROTECTED]> wrote:
Tambien, si estas usando NH, te va a servir para los testings usar el
ExportSchema
----------------------------------------------------------------------------
rdi2k | Ezequiel Jadib | MSN: [EMAIL PROTECTED] | Blog:
ejadib.wordpress.com
----- Original Message -----
From: Diego Jancic
To: patrones List Member
Sent: Thursday, December 07, 2006 9:43 AM
Subject: [patrones] Testing
Hola,
Oks... Entonces un DELETE ustedes lo hacen asi:
INSERT
SELECT // ASSERT
DELETE
SELECT // ASSERT
Yo siempre crei que estaba mal realizar tantos tests adentro de una
operacion simple, porque si el INSERT falla, el test del delete tambien...
A Dario Quintana: Gracias!, no se me habia ocurrido mirar ahi... creo que
ellos la deben tener clara..
Gracias a todos por las respuestas!, ahora voy a leer los links que
mandaron..
Saludos!
On 12/7/06, Alejandra Becerra < [EMAIL PROTECTED]> wrote:
Diego te cuento mi experiencia
1) Pensaría primero en la factibilidad de tener una base de datos real.
El tema de los mocks objects desde mi punto de vista está pensado para disponer
de algo cuando realmente no lo tenes. Si se necesita interactuar con algo que
aún no está desarrollado, simulas esa interface para no trabar tu desarrollo.
2)Cada test debería estar pensado para que si falla, falle por un bug,
y no por el desarrollo del propio test. Se puede testear el ID
independientemente de cómo este actualmente la base de datos, a no ser que
quieras hacer el test inicio de la base de datos, o el test de los valores
iniciales de la base de datos. Entonces dejar un valor fijo como id me parece
un error. El mismo test deberia crearlo y verificarlo.
3)Si es un proceso que va a ser repetitivo pensaría en hacer algo
automático.
4)No se me presento la necesidad.
Bueno espero que te sirva,
Alejandra
Diego Jancic <[EMAIL PROTECTED]> escribió:
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
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
