Cuando es necesario probar filtros de busqueda?

[Jose Vicente Martinez Mendoza]

Hola,

Estoy recien empezando con TDD y que mejor forma que practicando?

Para eso he empezado un pequeño "pet project" donde me ha surgido la duda sobre si tengo o no que realizar pruebas sobre una pagina donde básicamente sera un listado de posts (o lo que sea) sobre el que se podrán realizar diferentes filtrados como por ejemplo ver los pots de un determinado periodo (mes, año,...), poder moverse por elementos del periodo y/o filtrar por alguna categoría. En teoría toda la funcionalidad es realizar diferentes tipos de filtros sobre un listado.

De lo que he leído/investigado lo normal es no probar el CRUD porque suponemos que funciona, pero y si no? como se que funciona correctamente?

Que opináis, se tendría que probar o no?

Un saludo

[Edson Chavez]

Hola Jose, yo suelo hacer pruebas a las operaciones CRUD, mas no siempre como TDD, en mi caso como son operaciones contra la base de datos los suelo hacer despues de la programacion de la funcionalidad, (no me miren mal son mas pesadas y toman mas tiempo asi que las dejo para el final del dia) puesto que implican mas cosas como crear base de datos, tablas, tener la bd arriba, tener data de prueba para validar busquedas y resultados correctos a las busquedas y demas etc. que en caso de fallar la prueba tomaria mas tiempo de corregir, en algunos casos he hecho tdd con ese tipo de operaciones pero solo cuando ya tenia la aplicacion y la base de datos integrada y corriendo

en resumen si puedes y considero que debes testear (especialmente si tienes busquedas por criterios que implican relaciones de varias tablas) mas no necesariamente como TDD 

Saludos

Edson 'Grubhart'
http://www.sindominio.net/ayuda/preguntas-inteligentes.html
http://soyfreakytambiengeek.blogspot.com/ <-- Mi Blog ^^
@Grubhart   <-- Twitter!!

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

[José Manuel Beas]

Una cosa es probarte (a ti mismo) que sabes usar tu framework de elección y que sabes hacer consultas a la base de datos y otra muy distinta demostrar que tu sistema es capaz de cumplir con los criterios de aceptación de esas historias de usuario que planteas:

- ver el último post completo

- ver los últimos 10 posts completos

- ver una lista de los títulos de todos los posts de un mes dado

- ver una lista de los titulos de todos los posts de una categoría dada

...

Nota: Ahí no estamos hablando de base de datos para nada y mucho menos de CRUD ;)

Un saludo,
Jose Manuel Beas

http://jmbeas.es

http://agilismo.es

http://twitter.com/jmbeas

2011/12/1 Jose Vicente Martinez Mendoza <joma...@gmail.com>

[jorge baez]

ni de la erre?

[Jose Vicente Martinez Mendoza]

Pero al probar los criterios de aceptación estas probando indirectamente el framework, no? Pero claro a un nivel superior más a nivel de aplicación que a nivel de framework. Esa es lo que pensaba yo pero no se hasta que punto estaba probando el framework o la aplicación.

Un saludo

--
Jose

twitter: @jomarmen

[José Manuel Beas]

La erre la pruebas con las pruebas de aceptación.

Un saludo,
Jose Manuel Beas

http://jmbeas.es

http://agilismo.es

http://twitter.com/jmbeas

2011/12/1 jorge baez <jorge...@gmail.com>

[José Manuel Beas]

Exacto. Pero no vamos a hacer nosotros las pruebas que ya han hecho los fabricantes del framework, verdad? ;)

[Edson Chavez]

considerarian que una razon valida podria ser probar si tu sentencia de consulta esta bien escrita? , esto tambien lo puedes hacer si testeas el metodo que busca como menciono carlos, pero si esta prueba no incluye la integracion a la base de datos (es decir usas mocks para simular una conexion y un resultado de la bd)  no estas testeando que la consulta sea correcta solo que tu aplicacion interprete bien el resultado de la consulta, algo diferente es que quieras hacerle una prueba al metodo que ejecuta dicha sentencia. personalmente si tomo esa opcion y suelo hacer una prueba directa a ese metodo para tener garantias sobre si la consulta esta trayendo realmente lo que quiero que traiga, aunque como mencione antes involucra un poco mas de trabajo al necesitar una bd y datos de prueba sobre los que ejecutar la consulta. 

Edson 'Grubhart'
http://www.sindominio.net/ayuda/preguntas-inteligentes.html
http://soyfreakytambiengeek.blogspot.com/ <-- Mi Blog ^^
@Grubhart   <-- Twitter!!

[Ernesto Arroyo]

Bueno, hay distintos tipos de pruebas: unitarias, integración, carga, aceptación, de seguridad,... mixtas supongo que también habrá... lo que dbemos pensar es si alguno tendría los co..... de presentarle una demo a un cliente empezando la misma con una frase como "por cierto, este filtro de búsqueda que te voy a enseñar ahora no lo he probado antes"

Sea como sea, hay que probarlo. Lo ideal es que haya pruebas automáticas-automatizadas,... o buscar un becario,... pero hay que probarlo!

Ernesto Arroyo

... enviado desde mi iPad

[José Manuel Beas]

Alguien ha dicho lo contrario? ;)

Un saludo,
José Manuel Beas
http://jmbeas.es

[Alfredo Casado]

Bueno respondiendo a la pregunta: "Cuando hay que probar X" la respuesta es facil, sólo hay que probarlo en aquellos casos en los que quieras que funcione :P

Vamos que la discusión en todo caso estaría en que tipo de pruebas conviene hacer y en que momento hacerlas, en mi opinión la única forma de probar que una query/filtro esta bien escrito es ejecutandolo contra una base de datos, yo en este caso siguiendo un poco BDD empezaría por la prueba de aceptación/funcional de la tarea aunque probablemente no a nivel de UI sino a nivel de clases, y luego como siempre hacia abajo haciendo pruebas unitarias.

vamos que lo primero sería escribir algo como:

@Test

public void debe_filtrar_por_X() {

  // crear datos de prueba

  // ejecutar el filtro

  // comprobar que los resultados son los esperados

}

Esto es lo primero que haría en esta tarea antes de ninguna otra cosa, y cuando este test pase se que he terminado mi tarea y además tengo una prueba de regresión para forever and ever.