TDD con SQL y funciones de manipulación de datos

14

Aunque soy un programador profesional, nunca me formé formalmente en ingeniería de software. Cuando visito con frecuencia aquí y SO, he notado una tendencia para escribir pruebas unitarias siempre que sea posible y, a medida que mi software se vuelve más complejo y sofisticado, veo las pruebas automatizadas como una buena idea para ayudar a la depuración.

Sin embargo, la mayor parte de mi trabajo implica escribir SQL complejo y luego procesar la salida de alguna manera. ¿Cómo escribiría una prueba para asegurarse de que su SQL estaba devolviendo los datos correctos, por ejemplo? Luego, diga si los datos no estaban bajo su control (por ejemplo, el de un sistema de terceros), ¿cómo puede probar sus rutinas de procesamiento de manera eficiente sin tener que escribir manualmente resmas de datos ficticios?

La mejor solución que se me ocurre es hacer vistas de los datos que, juntos, cubren la mayoría de los casos. Luego puedo unir esas vistas con mi SQL para ver si está devolviendo los registros correctos y procesar manualmente las vistas para ver si mis funciones, etc. están haciendo lo que se supone que deben hacer. Aún así, parece excesivo y flaco; particularmente encontrando datos para probar contra ...

    
pregunta Xophmeister 25.08.2012 - 14:55

4 respuestas

6

Una regla importante para probar todo lo que está relacionado con la base de datos es aislarlo completamente del resto de su aplicación.

La arquitectura de puertos y adaptadores es un muy buen ejemplo. La base de datos se considera como un complemento externo a través de un adaptador para su aplicación. Lo mismo ocurre con todos los subsistemas de terceros. Para probar cómo se comportaría su aplicación e interpretar las respuestas de los subsistemas de terceros, la única manera que conozco de cómo probar es aplazar las respuestas de este subsistema individual. No significa necesariamente que tenga que escribir manualmente todos los objetos de datos. Puede adoptar fácilmente el enfoque de utilizar pruebas basadas en datos.

En lo que respecta a probar cómo interactúa su aplicación con su base de datos, puede falsificar los adaptadores de base de datos para usar una base de datos en memoria, por ejemplo.

Ahora probando sus consultas de base de datos. En primer lugar, todas las consultas complejas deben descomponerse en consultas más fáciles, simples y predecibles. Lo mismo que harías para una clase de grasa o para una función de grasa. Existen herramientas que pueden ayudarlo a probar su base de datos como Dbunit . Un enfoque simple que a veces tomo es usar el concepto de pruebas de caracterización. Así que pondría la base de datos en un estado de conocimiento, ejecutaría todas las consultas que tengo que escribir, guarde la salida en un lugar (archivo, memoria) y considero que esta es la correcta. Las siguientes ejecuciones compararían su salida con esta, por lo que definitivamente me ofrecería las pruebas de regresión que necesito. De hecho, no se garantiza que la primera salida sea correcta, pero el problema de regresión se puede resolver de esta manera. Si sus consultas están bien descompuestas, puede probarlas individualmente en la base de datos que se encuentra en un estado conocido.

    
respondido por el Vadim 25.08.2012 - 15:22
3

Esa es una pregunta interesante porque la base de datos suele ser la parte falsificada durante la prueba de la unidad de la aplicación. Es de esperar que la lógica del motor de la base de datos en sí esté bien probada por el proveedor, pero, por supuesto, las consultas, el esquema y los procedimientos almacenados son códigos que deben probarse y protegerse contra la regresión. A menudo, esto se deja para pruebas de integración que no son TDD.

Es probable que las vistas

sean una forma difícil de hacerlo porque realmente no se prestan a la prueba la primera prueba de luz roja, luz verde automática de un aspecto por prueba que se prefiere en TDD. Además, con las vistas no se puede escribir la prueba antes del código. Un enfoque mejor sería escribir procedimientos almacenados donde puede agregar lógica "afirmar" en el procedimiento (por ejemplo, utilizando declaraciones "if") para probar la salida en busca de fallos. Necesita probar solo una cosa en cada prueba de unidad para aislar la unidad, y el método SP sería más adecuado para eso. Además, con los SP, puede ejecutar todo el conjunto de ellos como scripts a medida que desarrolla el código inicial y, posteriormente, cuando pruebe las regresiones al refactorizar.

Además, tenga en cuenta que las pruebas deben ser repetibles y necesitará algunos scripts para inicializar y demoler el estado de la base de datos para asegurarse de que el estado sea el mismo para cada prueba de unidad.

Para su pregunta sobre datos que no están bajo su control, es un área difícil. Creo que es mejor que te burles de ellos con datos falsos y que pruebes las condiciones de excepción y de borde tanto como sea posible para las pruebas unitarias. De lo contrario, caerá más en la categoría de pruebas de integración (que también es una buena cosa que hacer). Para las pruebas de integración, puede ejecutar sus pruebas con datos de terceros y dejar que genere una salida inicial y para las pruebas posteriores (por ejemplo, después de la refactorización) asegúrese de que esas salidas repitan la salida inicial conocida.

    
respondido por el Turnkey 25.08.2012 - 15:46
1

En algún momento vas a necesitar datos de prueba. Si está utilizando un sistema de terceros, el esquema ya se ha creado, pero deberá abordar los cambios futuros. Con suerte, puede obtener estos cambios en la documentación de actualización, pero puede verse obligado a comparar las versiones de la base de datos usted mismo.

Los conjuntos de resultados esperados se pueden guardar en tablas de base de datos o en archivos / hojas de cálculo externos. Incluso he visto CHECKSUM usado o comparación. Cuando prueba una vista / sproc, obtendrá un error ya que no existen. Luego, crea el objeto con suficiente código para al menos ejecutar (SELECCIONE -1 como [ddatos incorrectos];) y obtendrá un error porque no coincide con el conjunto de resultados. Una vez que coincidan, tendrás tu luz verde.

Empecé a trabajar con los propietarios de proyectos y les pido que simulen informes en una hoja de cálculo e intenten crear datos parciales para mí (podría poner los datos de resultados en una tabla de prueba). Al principio hubo algo de rechazo, pero se dieron cuenta de que crearé un informe y tendrán que verificarlo de todos modos. Esto ha ahorrado tiempo a largo plazo. Si desean realizar una solicitud de cambio, pueden rehacer la hoja de cálculo. Ahora pueden responder la pregunta: "¿Qué tan difícil sería agregar ...?"

    
respondido por el JeffO 26.08.2012 - 14:51
1

Si su plataforma de base de datos es SQL Server, hay una muy buena herramienta gratuita: tSQLt .

  

tSQLt es un marco de prueba de unidad de base de datos para Microsoft SQL Server. tSQLt es compatible con SQL Server 2005 (se requiere service pack 2) y superior en todas las ediciones.

He utilizado con éxito para implementar pruebas en el nivel de la base de datos.

Algunos de los elementos clave que lo hacen tan útil incluyen:

  • Capacidad para trabajar con tablas y vistas falsas, lo que reduce la configuración normal involucrada
  • Las pruebas se ejecutan automáticamente en transacciones (tan fácilmente re-ejecutables)
  • Sus afirmaciones pueden hacer comparaciones en tablas (tanto reales como falsas) para que pueda ver si ha cambiado algún dato fácilmente
respondido por el Alain King 27.08.2012 - 13:19

Lea otras preguntas en las etiquetas