[patrones] Testing

2006-12-07 Por tema Diego Jancic

Bueno... lo del TearUp lo hice de memoria y aparentemente lo invente =P...
pero hay un TestFixtureSetUp que se ejecuta 1 sola ves por TextFixture... ;)

Gracias Carlos por las respuestas! Me falta un poco de practica en el
tema

Saludos!,
Diego


On 12/7/06, Carlos Peix <[EMAIL PROTECTED]> wrote:


 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 lentsimo.

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




[patrones] Testing

2006-12-07 Por tema Carlos Peix
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 lentsimo.
 
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



[patrones] Testing

2006-12-07 Por tema Ezequiel Jadib
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 






[patrones] Testing

2006-12-07 Por tema Diego Jancic

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 <http://www.rdi2k.com/> | Ezequiel Jadib <[EMAIL PROTECTED]> | MSN:
[EMAIL PROTECTED] | Blog: ejadib.wordpress.com

- Original Message -
*From:* Diego Jancic <[EMAIL PROTECTED]>
*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
>




[patrones] Testing

2006-12-07 Por tema Ezequiel Jadib
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 




[patrones] Testing

2006-12-07 Por tema Diego Jancic

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



[patrones] Testing

2006-12-07 Por tema Ezequiel Jadib
Leete esto diego.. quizas te sirva.. para el punto 2

http://ejadib.wordpress.com/2006/12/05/extending-unit-testing-in-visual-studio-team-system/



rdi2k | Ezequiel Jadib | MSN: [EMAIL PROTECTED] | Blog: ejadib.wordpress.com 
  - Original Message - 
  From: Diego Jancic 
  To: patrones List Member 
  Sent: Thursday, December 07, 2006 12:18 AM
  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


[patrones] Testing

2006-12-07 Por tema Alejandra Becerra
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

[patrones] Testing

2006-12-06 Por tema Luis Farzati

Una cosa más que obvié: tenemos dos DB. Una para desarrollar (como te
contaba antes, todos la usamos durante el proceso de desarrollo, debugging,
etc) y otra que sólo es usada para los tests que se ejecutan durante el
proceso de buildeo automático.

Saludos,
Luis


On 12/7/06, Luis Farzati <[EMAIL PROTECTED]> wrote:


Hola Diego,

Mirá, en un proyecto en el que estoy trabajando actualmente la forma de
encararlo fue la siguiente: en una primera iteración de la capa de datos,
los tests fueron ejecutados contra mocks. En iteraciones posteriores los
realizamos contra la DB actual (una sola, centralizada), salvo que exista
funcionalidad nueva. La frecuencia con la que corren los tests contra la DB
no mockeada es cada vez que se comitean cambios en el SVN ya que usamos CI
con CruiseControl.NET.

La 2 no la entendí muy bien... En los tests también hacemos los CRUDs,
aunque no lo hacemos por separado, si es a lo que te referis. En un mismo
tests hacemos todo, desde la creación hasta la eliminación. Esto lo hacemos
así porque las operaciones por separado se van a terminar ejecutando en los
tests de capas superiores, no en los de la DAL.

Para el caso del mock ponemos obviamente inicialización mock. En la DB
real los scripts se corren a mano pero la verdad que no es algo que hagamos
con frecuencia. Se inicializa una vez la DB de desarrollo y a menos que haya
cambios en el schema, los tests se ejecutan sobre lo que hay.

Con respecto a lo último, estuve leyendo (posiblemente los mismos
artículos =P) y al menos en nuestro caso, hasta ahora no tuvimos la
necesidad de tener una DB cada uno. Personalmente creo que eso depende del
tipo de solución que estén armando. Tal vez si es algo con muchas
transacciones o delicado en cuanto a consistencia y/o contenido (onda, estoy
probando y si me agregás un registro tengo que empezar de nuevo) entonces
puede ser.

Saludos!
Luis


On 12/7/06, Diego Jancic <[EMAIL PROTECTED]> wrote:
>
>  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
>




[patrones] Testing

2006-12-06 Por tema Luis Farzati

Hola Diego,

Mirá, en un proyecto en el que estoy trabajando actualmente la forma de
encararlo fue la siguiente: en una primera iteración de la capa de datos,
los tests fueron ejecutados contra mocks. En iteraciones posteriores los
realizamos contra la DB actual (una sola, centralizada), salvo que exista
funcionalidad nueva. La frecuencia con la que corren los tests contra la DB
no mockeada es cada vez que se comitean cambios en el SVN ya que usamos CI
con CruiseControl.NET.

La 2 no la entendí muy bien... En los tests también hacemos los CRUDs,
aunque no lo hacemos por separado, si es a lo que te referis. En un mismo
tests hacemos todo, desde la creación hasta la eliminación. Esto lo hacemos
así porque las operaciones por separado se van a terminar ejecutando en los
tests de capas superiores, no en los de la DAL.

Para el caso del mock ponemos obviamente inicialización mock. En la DB real
los scripts se corren a mano pero la verdad que no es algo que hagamos con
frecuencia. Se inicializa una vez la DB de desarrollo y a menos que haya
cambios en el schema, los tests se ejecutan sobre lo que hay.

Con respecto a lo último, estuve leyendo (posiblemente los mismos artículos
=P) y al menos en nuestro caso, hasta ahora no tuvimos la necesidad de tener
una DB cada uno. Personalmente creo que eso depende del tipo de solución que
estén armando. Tal vez si es algo con muchas transacciones o delicado en
cuanto a consistencia y/o contenido (onda, estoy probando y si me agregás un
registro tengo que empezar de nuevo) entonces puede ser.

Saludos!
Luis


On 12/7/06, Diego Jancic <[EMAIL PROTECTED]> wrote:


 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



[patrones] Testing

2006-12-06 Por tema Dario Quintana

Hola Diego, como estás, mirá no estoy mucho en el tema de testing,
pero ya que estás en el tema, mirá un poquito los test de NHibernate,
lo muchachos lo hacen de manera bastante elegante...y van derecho
contra la base.

Saludos

On 12/7/06, Diego Jancic <[EMAIL PROTECTED]> wrote:





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



--
Dario Quintana
darionet.wordpress.com



[patrones] Testing

2006-12-06 Por tema Diego Jancic
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