Testeo de persistencia
49 views
Skip to first unread message
belano
Oct 15, 2010, 3:07:51 PM10/15/10
to Artesanos de Software
Hola a todos.
Estoy leyendo el (estupendo) libro Growing OO Software Guided By
Tests, me encuentro en el capítulo 25 en el cual trata el testeo de
persistencia. Aquí proponen una implementación en la que los tests
persisten realmente los datos y manualmente hacen una limpieza tras
cada test, en oposición a por ejemplo las clases de soporte de Spring
las cuales se encargan de hacer un rollback automático al final de
cada test.
Me gustaría conocer vuestras opiniones sobre los pros y contras de
ambas opciones, yo ando ahora mismo algo confundido…
Saludos.
Estoy leyendo el (estupendo) libro Growing OO Software Guided By
Tests, me encuentro en el capítulo 25 en el cual trata el testeo de
persistencia. Aquí proponen una implementación en la que los tests
persisten realmente los datos y manualmente hacen una limpieza tras
cada test, en oposición a por ejemplo las clases de soporte de Spring
las cuales se encargan de hacer un rollback automático al final de
cada test.
Me gustaría conocer vuestras opiniones sobre los pros y contras de
ambas opciones, yo ando ahora mismo algo confundido…
Saludos.
Alfredo Casado
Oct 15, 2010, 6:43:05 PM10/15/10
to artesanos-...@googlegroups.com
No conozco las clases de spring, pero si los test al final hacen rollback entonces no estas probando si haces o no haces commit, cuando se involucra a una bd en los test en mi opinión lo suyo es comprobar que toda la interacción con la base de datos es correcta y eso incluye hacer commit. Aunque los commit los haga el framework por configuración, habrá que probar que esa configuración sea correcta y hayas demarcado correctamente el scope de las transacciones, no me parece un tema precisamente menor como para que tus test no lo tengan en cuenta. Otro tema es cuando quieres probar varios usuarios (conexiones a bd) que hacen modificaciones/lecturas concurrentes, si no haces commit no puedes hacer este tipo de test.
Nosotros en este tipo de test lo que hacemos es establecer un estado conocido en la bd antes de cada test, esto lo hacemos limpiándola y luego mediante builders (otro patrón del goos) creamos los datos de prueba, antes lo hacíamos con dbunit y ficheros xml con los datos de prueba y fue un desastre, luego no hay quien mantenga tanto xml con datos de prueba.
Rafael Gutiérrez
Oct 15, 2010, 6:35:48 PM10/15/10
to artesanos-...@googlegroups.com
Que tal,
Yo he usado la opción de que cada Test hace limpieza después de cada test y ahora con JPA/Spring y el rollback automático estoy muy agradecido (trabajo menos).
Pero bueno, esa es mi opinión la verdad no me he puesto a ver si hay alguna ventaja de uno sobre otro.
Saludos
belano
Oct 18, 2010, 2:59:42 AM10/18/10
to Artesanos de Software
Gracias por las respuestas.
Por mi parte, hace tiempo también solía utilizar dbunit + xml para
preparar el estado de los tests pero desde que descubrí las clases de
soporte de Spring (eg. AbstractTransactionalJUnit4SpringContextTests)
y el patrón Builder cambié de forma de trabajar.
Me parece entender que los argumentos que exponen en goos van en la
misma linea de lo que comenta Alfredo, y son lo suficientemente
importantes como para tenerlos en cuenta:
"A test that never commits does not fully exercise how the code under
test interacts with the database. Neither can it test interactions
between distinct
transactions. Another disadvantage of rolling back is that the test
discards data
that might be useful for diagnosing failures."
Seguiré evaluando ambas formas de testeo.
Gracias de nuevo.
Saludos.
On Oct 16, 12:35 am, Rafael Gutiérrez <abadon.gutier...@gmail.com>
wrote:
Por mi parte, hace tiempo también solía utilizar dbunit + xml para
preparar el estado de los tests pero desde que descubrí las clases de
soporte de Spring (eg. AbstractTransactionalJUnit4SpringContextTests)
y el patrón Builder cambié de forma de trabajar.
Me parece entender que los argumentos que exponen en goos van en la
misma linea de lo que comenta Alfredo, y son lo suficientemente
importantes como para tenerlos en cuenta:
"A test that never commits does not fully exercise how the code under
test interacts with the database. Neither can it test interactions
between distinct
transactions. Another disadvantage of rolling back is that the test
discards data
that might be useful for diagnosing failures."
Seguiré evaluando ambas formas de testeo.
Gracias de nuevo.
Saludos.
On Oct 16, 12:35 am, Rafael Gutiérrez <abadon.gutier...@gmail.com>
wrote:
> Que tal,
>
> Yo he usado la opción de que cada Test hace limpieza después de cada test y
> ahora con JPA/Spring y el rollback automático estoy muy agradecido (trabajo
> menos).
>
> Pero bueno, esa es mi opinión la verdad no me he puesto a ver si hay alguna
> ventaja de uno sobre otro.
>
> Saludos
>
> Rafael Gutiérrez
>
> 2010/10/15 belano <dielisb...@gmail.com>
>
> Yo he usado la opción de que cada Test hace limpieza después de cada test y
> ahora con JPA/Spring y el rollback automático estoy muy agradecido (trabajo
> menos).
>
> Pero bueno, esa es mi opinión la verdad no me he puesto a ver si hay alguna
> ventaja de uno sobre otro.
>
> Saludos
>
> Rafael Gutiérrez
>
Ricardo Borillo
Oct 18, 2010, 3:58:57 AM10/18/10
to artesanos-...@googlegroups.com
Hola a todos,
Me parecen muy interesantes estas opciones que estais planteando,
¿Sería posible que alguien ilustrara la opción de los builders o de
Spring con algún ejemplo concreto de código o con alguna referencia
para poder hacerme una idea más clara de como montar este tipo
escenarios reemplazado dbUnit?
La verdad es que llevo algún tiempo con dbUnit y no está siendo lo
productivo que esperaba en estos aspectos ...
---
Salut,
====================================
Ricardo Borillo Domenech
http://xml-utils.com
twitter: @borillo
2010/10/18 belano <dieli...@gmail.com>:
Joaquín Engelmo Moriche
Oct 18, 2010, 2:42:00 AM10/18/10
to artesanos-...@googlegroups.com
Buenas,
¿de qué tipo de test estamos hablando? Según está planteado el tema supongo que de integración ya que los unitarios estaría bien usaran una base de datos en memoria tipo HSQLDB.
Ahora mismo no recuerdo bien como es el proceso "de vuelta atrás" de Spring en los test para las operaciones de persistencia pero, como dice Alfredo, que haga rollback sin commit tampoco me convence (en el caso que sea realmente así). Además coincido con su solución, en mi caso, tendría una base de datos para integración y la prepararía para cada ejecución de test, limpiándola al final. Últimamente escucho mucho del libro GOOS, por vuestra culpa voy a tener que comprarlo :P
Entiendo que Spring, por ejemplo, facilita la gestión con su proceso pero habría que ver exactamente si cubre el commit, sobre todo por el tema de las transacciones y acceso concurrente como dice Alfredo.
Un saludo :)
--
"Compartiendo el agilismo"
"Compartiendo el agilismo"
Agile Open Space 2010 - Barcelona 12 y 13 de noviembre
Eduardo Ferrández
Oct 18, 2010, 11:45:19 AM10/18/10
to artesanos-...@googlegroups.com
¿de qué tipo de test estamos hablando? Según está planteado el tema supongo que de integración ya que los unitarios estaría bien usaran una base de datos en memoria tipo HSQLDB.
Buenas
Entiendo que un test que depende de un sistema externo no es unitario, por tanto cualquier test con acceso a base de datos será, como mínimo, de integración. Otra cosa es que busquemos mecanismos para conseguir una ejecución más rápida de esos tests, como el uso de una base de datos en memoria.
Alejandro Cuesta
Oct 19, 2010, 5:18:02 PM10/19/10
to Artesanos de Software
Spring hace rollback por defecto.
Yo los he hecho de las dos formas con commit y con rollback. Entiendo
lo que plantea GOOS pero hasta ahora no he tenido ningun problema
haciendo rollback en cada test. Si que he tenido alguno haciendo
commits. Hace unos meses oi una frase de un speaker que se me quedo:
"Testear todo al 100% es difícil y puedes llegar a volverte loco". Por
esa regla de tres sería mejor testear con la que vamos a usar en
producción, no con una HSQL o H2.
Yo si he leido el librito GOOS hace unos 6 meses y recuerdo que me
decepcionó un poquillo, la verdad.
Lo mejor es coger un poco de alli, otro poco de alla y aplicar lo
aprendido segun el caso, con cabeza.
Alex
On Oct 18, 7:42 am, Joaquín Engelmo Moriche <kinisoftw...@gmail.com>
wrote:
Yo los he hecho de las dos formas con commit y con rollback. Entiendo
lo que plantea GOOS pero hasta ahora no he tenido ningun problema
haciendo rollback en cada test. Si que he tenido alguno haciendo
commits. Hace unos meses oi una frase de un speaker que se me quedo:
"Testear todo al 100% es difícil y puedes llegar a volverte loco". Por
esa regla de tres sería mejor testear con la que vamos a usar en
producción, no con una HSQL o H2.
Yo si he leido el librito GOOS hace unos 6 meses y recuerdo que me
decepcionó un poquillo, la verdad.
Lo mejor es coger un poco de alli, otro poco de alla y aplicar lo
aprendido segun el caso, con cabeza.
Alex
On Oct 18, 7:42 am, Joaquín Engelmo Moriche <kinisoftw...@gmail.com>
wrote:
> Buenas,
>
> ¿de qué tipo de test estamos hablando? Según está planteado el tema supongo
> que de integración ya que los unitarios estaría bien usaran una base de
> datos en memoria tipo HSQLDB.
>
> Ahora mismo no recuerdo bien como es el proceso "de vuelta atrás" de Spring
> en los test para las operaciones de persistencia pero, como dice Alfredo,
> que haga rollback sin commit tampoco me convence (en el caso que sea
> realmente así). Además coincido con su solución, en mi caso, tendría una
> base de datos para integración y la prepararía para cada ejecución de test,
> limpiándola al final. Últimamente escucho mucho del libro GOOS, por vuestra
> culpa voy a tener que comprarlo :P
>
> Entiendo que Spring, por ejemplo, facilita la gestión con su proceso pero
> habría que ver exactamente si cubre el commit, sobre todo por el tema de las
> transacciones y acceso concurrente como dice Alfredo.
>
> Un saludo :)
>
> El 16 de octubre de 2010 00:35, Rafael Gutiérrez <abadon.gutier...@gmail.com
>
> ¿de qué tipo de test estamos hablando? Según está planteado el tema supongo
> que de integración ya que los unitarios estaría bien usaran una base de
> datos en memoria tipo HSQLDB.
>
> Ahora mismo no recuerdo bien como es el proceso "de vuelta atrás" de Spring
> en los test para las operaciones de persistencia pero, como dice Alfredo,
> que haga rollback sin commit tampoco me convence (en el caso que sea
> realmente así). Además coincido con su solución, en mi caso, tendría una
> base de datos para integración y la prepararía para cada ejecución de test,
> limpiándola al final. Últimamente escucho mucho del libro GOOS, por vuestra
> culpa voy a tener que comprarlo :P
>
> Entiendo que Spring, por ejemplo, facilita la gestión con su proceso pero
> habría que ver exactamente si cubre el commit, sobre todo por el tema de las
> transacciones y acceso concurrente como dice Alfredo.
>
> Un saludo :)
>
>
>
>
> > escribió:
> > Que tal,
>
> > Yo he usado la opción de que cada Test hace limpieza después de cada test y
> > ahora con JPA/Spring y el rollback automático estoy muy agradecido (trabajo
> > menos).
>
> > Pero bueno, esa es mi opinión la verdad no me he puesto a ver si hay alguna
> > ventaja de uno sobre otro.
>
> > Saludos
>
> > Rafael Gutiérrez
>
> > 2010/10/15 belano <dielisb...@gmail.com>
>
>
> > escribió:
> > Que tal,
>
> > Yo he usado la opción de que cada Test hace limpieza después de cada test y
> > ahora con JPA/Spring y el rollback automático estoy muy agradecido (trabajo
> > menos).
>
> > Pero bueno, esa es mi opinión la verdad no me he puesto a ver si hay alguna
> > ventaja de uno sobre otro.
>
> > Saludos
>
> > Rafael Gutiérrez
>
Alfredo Casado
Oct 19, 2010, 6:49:40 PM10/19/10
to artesanos-...@googlegroups.com
Por esa regla de tres sería mejor testear con la que vamos a usar en producción, no con una HSQL o H2.
¿No testeas con tu la bd que vas a tener en producción?, me parece un tema fundamental teniendo en cuenta las enormes diferencias de comportamiento entre distintos SGBD's, en mi opinión es una locura no testear con la bd que vas a usar e producción.
Nosotros tenemos varios perfiles en maven, una para cada bd, en el trabajo diario hacemos test con HSQL y sólo en algunos casos especiales lanzamos contra otras bd desde local (que cuesta un segundo cambiar el perfil), y luego por las noches en el entorno de IC, en nuestro caso hudson, tenemos jobs para lanzar los test contra MySql, oracle y sql-server. De modo que si la cagamos y hacemos algo que no funciona para alguno de los SGBD's que tenemos que soportar como mucho en un día tenemos el feedback del problema para arreglarlo. En el pasado nos "relajamos" con la practica de probar con todos los SGBD's que tenemos que soportar y bueno... la cagamos bastante.
Testear todo al 100% es difícil y puedes llegar a volverte loco
Me parece más peligrosa que otra cosa esa frase, ¿vas a ejecutar código en producción sin testearlo de algún modo?, ¿cual es la garantía entonces que le puedes dar al cliente de que funciona?. Esta claro que a veces hay cosas realmente complejas de testear, pero la frase anterior es una salida demasiado fácil que muchos pueden tomar como excusa para no hacer algo que si lo intentas a lo mejor descubres que no es tan difícil. Conste que no digo que tu lo hagas eh!, simplemente que no me parece un buen consejo en general, creo que para poder mejorar es necesario huir de actitudes tan conformistas.
Prefiero esta otra frase: "como nadie les dijo que era imposible, lo hicierón"
belano
Oct 20, 2010, 3:33:31 AM10/20/10
to Artesanos de Software
Ricardo,
Te copio y pego un ejemplo mezcla de Buiders y el soporte
transaccional de Spring.
http://snipt.net/belano/ejemplo-testing
Se agradecen comentarios.
Saludos
On Oct 18, 9:58 am, Ricardo Borillo <Ricardo.Bori...@si.uji.es> wrote:
> Hola a todos,
>
> Me parecen muy interesantes estas opciones que estais planteando,
> ¿Sería posible que alguien ilustrara la opción de los builders o de
> Spring con algún ejemplo concreto de código o con alguna referencia
> para poder hacerme una idea más clara de como montar este tipo
> escenarios reemplazado dbUnit?
>
> La verdad es que llevo algún tiempo con dbUnit y no está siendo lo
> productivo que esperaba en estos aspectos ...
>
> ---
> Salut,
> ====================================
> Ricardo Borillo Domenechhttp://xml-utils.com
> twitter: @borillo
>
> 2010/10/18 belano <dielisb...@gmail.com>:
Te copio y pego un ejemplo mezcla de Buiders y el soporte
transaccional de Spring.
http://snipt.net/belano/ejemplo-testing
Se agradecen comentarios.
Saludos
On Oct 18, 9:58 am, Ricardo Borillo <Ricardo.Bori...@si.uji.es> wrote:
> Hola a todos,
>
> Me parecen muy interesantes estas opciones que estais planteando,
> ¿Sería posible que alguien ilustrara la opción de los builders o de
> Spring con algún ejemplo concreto de código o con alguna referencia
> para poder hacerme una idea más clara de como montar este tipo
> escenarios reemplazado dbUnit?
>
> La verdad es que llevo algún tiempo con dbUnit y no está siendo lo
> productivo que esperaba en estos aspectos ...
>
> ---
> Salut,
> ====================================
> twitter: @borillo
>
> 2010/10/18 belano <dielisb...@gmail.com>:
Ricardo Borillo
Oct 20, 2010, 5:09:51 AM10/20/10
to artesanos-...@googlegroups.com
Hola,
Muchas gracias por el ejemplo!! Ahora veo mucho más claro como usais
el patrón builder en estos casos :)
La verdad es que me viene genial, porque suelo utilizar Spring en mis
desarrollos y ya tengo los tests integrados con Spring.
---
Salut,
====================================
Ricardo Borillo Domenech
http://xml-utils.com
twitter: @borillo
2010/10/20 belano <dieli...@gmail.com>:
Alejandro Cuesta
Oct 20, 2010, 12:21:23 PM10/20/10
to Artesanos de Software
On Oct 19, 11:49 pm, Alfredo Casado <casado.alfr...@gmail.com> wrote:
> *Por esa regla de tres sería mejor testear con la que vamos a usar
> en producción, no con una HSQL o H2.*
> *
> *
> *¿No testeas con tu la bd que vas a tener en producción?, me parece un tema
> fundamental teniendo en cuenta las enormes diferencias de comportamiento
> entre distintos SGBD's, en mi opinión es una locura no testear con la bd que
> vas a usar e producción.*
> entre distintos SGBD's, en mi opinión es una locura no testear con la bd que
> *
> *
> *Nosotros tenemos varios perfiles en maven, una para cada bd, en el trabajo
> diario hacemos test con HSQL y sólo en algunos casos especiales lanzamos
> contra otras bd desde local (que cuesta un segundo cambiar el perfil), y
> luego por las noches en el entorno de IC, en nuestro caso hudson, tenemos
> jobs para lanzar los test contra MySql, oracle y sql-server. De modo que si
> la cagamos y hacemos algo que no funciona para alguno de los SGBD's que
> tenemos que soportar como mucho en un día tenemos el feedback del problema
> para arreglarlo. En el pasado nos "relajamos" con la practica de probar con
> todos los SGBD's que tenemos que soportar y bueno... la cagamos bastante.*
> contra otras bd desde local (que cuesta un segundo cambiar el perfil), y
> luego por las noches en el entorno de IC, en nuestro caso hudson, tenemos
> jobs para lanzar los test contra MySql, oracle y sql-server. De modo que si
> la cagamos y hacemos algo que no funciona para alguno de los SGBD's que
> tenemos que soportar como mucho en un día tenemos el feedback del problema
> para arreglarlo. En el pasado nos "relajamos" con la practica de probar con
>
Parece que no me explique bien. Yo hablaba de desarrollo local, no de
integracion.
> *Testear todo al 100% es difícil y puedes llegar a volverte loco*
> *
> *
> Me parece más peligrosa que otra cosa esa frase, ¿vas a ejecutar código en
> producción sin testearlo de algún modo?, ¿cual es la garantía entonces que
> le puedes dar al cliente de que funciona?. Esta claro que a veces hay cosas
> realmente complejas de testear, pero la frase anterior es una salida
> demasiado fácil que muchos pueden tomar como excusa para no hacer algo que
> si lo intentas a lo mejor descubres que no es tan difícil. Conste que no
> digo que tu lo hagas eh!, simplemente que no me parece un buen consejo en
> general, creo que para poder mejorar es necesario huir de actitudes tan
> conformistas.
>
> Prefiero esta otra frase: "como nadie les dijo que era imposible, lo
> hicierón"
>
Lo siento. Parece que la fiebre de ayer me jugo una mala pasada :(
> producción sin testearlo de algún modo?, ¿cual es la garantía entonces que
> le puedes dar al cliente de que funciona?. Esta claro que a veces hay cosas
> realmente complejas de testear, pero la frase anterior es una salida
> demasiado fácil que muchos pueden tomar como excusa para no hacer algo que
> si lo intentas a lo mejor descubres que no es tan difícil. Conste que no
> digo que tu lo hagas eh!, simplemente que no me parece un buen consejo en
> general, creo que para poder mejorar es necesario huir de actitudes tan
> conformistas.
>
> Prefiero esta otra frase: "como nadie les dijo que era imposible, lo
> hicierón"
>
Tienes razon, esta frase es peligrosa y la saque de contexto.
De todas formas, la dijo el jefe de calidad de Sky Net (creo recordar)
en una charla de tests de aceptacion.
Se referia a la incapacidad tecnica de automatizar totalmente cada
detalle de una aplicacion web.
> El 19 de octubre de 2010 23:18, Alejandro Cuesta <alejandro.cue...@gmail.com
Miguel Angel
Oct 20, 2010, 3:21:17 PM10/20/10
to Artesanos de Software
Comparto el método maven + hsql para trabajo en local y otro perfil
para test de regresión, ademas si tienes la mala suerte de usar
hibernate hay una opcion que te levanta el solito una instancia de
hsql y te crea la bd a partir de los hbm con lo que solo lanzas los
script de inserts.
En .net se puede hacer muy parecido con sqlserver compact edition.
para test de regresión, ademas si tienes la mala suerte de usar
hibernate hay una opcion que te levanta el solito una instancia de
hsql y te crea la bd a partir de los hbm con lo que solo lanzas los
script de inserts.
En .net se puede hacer muy parecido con sqlserver compact edition.
Reply all
Reply to author
Forward
0 new messages