¿Alguna vez está bien no probar una función?

12

¿Hay algún punto en el que se familiarice tanto con su idioma / base de datos / sistema que no sea necesario probar una nueva característica / configuración / consulta / etc. mediante pruebas contenidas / simuladas antes de implementarlo en su sistema (especialmente en relación con una función que modifica los datos)? ¿O siempre es esencial probar una nueva consulta por simulación en un entorno de prueba ?

Para especificar más, está claro que siempre es más seguro realizar pruebas. Sin embargo, ¿hay alguna forma de determinar cuándo el riesgo es tan mínimo que las pruebas no valen la pena? Otra forma de redactar eso: ¿cuándo o cuándo es una práctica profesional tomar un riesgo medido para implementar una función?

Además, supongamos que todo está respaldado, por lo que, en el peor de los casos, los datos podrían restaurarse con cierto esfuerzo.

¿Puede alguien citar experiencia específica y experta para abordar esto? Incluya referencias cuando sea apropiado / posible.

ZX9
fuente

Respuestas:

10

Quiero comenzar diciendo que todo lo que hago es SQL Server, así que esos son los ejemplos que doy. Sin embargo, en general, esto se aplica a cualquier forma de código, independientemente del sistema.

Comencemos desglosando esto un poco.

Actualizaciones

Tiene un sistema y está a punto de actualizarlo en parte o en su totalidad. Por ejemplo, actualizar una instancia de SQL Server 2012 a 2014. En este punto, las pruebas son esenciales. Desafortunadamente, probar cada parte de una pequeña aplicación probablemente no sea posible. En ese momento haría lo que llamaría una prueba de "trabajo". ¿Funciona el sistema básico? Ejecute sus tareas comunes de principio a fin. No pruebe todas las opciones, solo la ruta principal.

Al realizar una actualización de SQL Server, también se requiere alguna lectura . Básicamente, desea leer la Backward Compatibilityentrada para la nueva versión ( aquí está la 2014 ) y asegurarse de que no tiene nada en ninguna de las listas (cambios importantes, cambios de comportamiento, etc.).

Código de aplicación

Aquí estamos viendo un código de aplicación nuevo / cambiante (porque, por supuesto, todo lo existente ya ha sido probado, ¿verdad?). En este caso, todo debe ser probado. Debe configurar los casos de prueba con anticipación y ejecutar al menos la mayoría de sus funciones afectadas. Preferiblemente en este punto, también debería pedirle a otra persona que haga una verificación similar. Este código estará en su lugar, probablemente por un tiempo bastante largo, y será utilizado por una gran cantidad de personas. Desea asegurarse de que funciona y funciona bien.

Una de las cosas que realmente pueden ayudar con esto es generar un conjunto unit testsque sea fácilmente repetible. Steve Jones recomienda usar tSQLt para probar su código TSQL (solo SQL Server, me temo). Pero al hacer esto, puede ejecutar rápidamente un conjunto fijo de pruebas y realmente ayudará en las pruebas de regresión (probar todo, por ejemplo, antes de realizar una actualización).

Características / Configuraciones

Incluso más que los cambios en el código de la aplicación, desea probar nuevas características y cambios de configuración a fondo. Si, por ejemplo, decide comenzar a trabajar con índices de almacén de columnasPor primera vez, deberá probar cada código que toque las tablas afectadas. Use las pruebas unitarias que generó para probar su aplicación. Estas características son probablemente nuevas para usted (y posiblemente nuevas en la plataforma) y probablemente tendrán algunas trampas que no esperaba. En cuanto a los cambios de configuración, está hablando de algo que puede afectar a todo su sistema, posiblemente de manera significativa. La regla general es probar y probar con cuidado. Hay algunos cambios que realmente no verá hasta que ingrese a un sistema activo (posiblemente solo su sistema de producción), pero eso no es una excusa para no probarlos primero en un entorno de prueba.

Consultas ad hoc que hacen referencia / afectan los datos del usuario

Cuando tiene un código que afecta sus datos de usuario, generalmente necesita probarlo, incluso, y quizás especialmente, porque lo es Ad Hoc. Dicho esto, si está ejecutando el mismo código, una y otra vez, solo con diferentes parámetros, entonces probablemente no tenga que preocuparse por las pruebas cada vez.

Por ejemplo, debe eliminar uno o más anuncios de la tabla AdList cada trimestre.

DELETE FROM AdList WHERE AdName IN ('January 2015 Ads','February 2015 Ads','March 2015 Ads')

En ese momento ya ha probado el código (solo está cambiando las cadenas fijas) y probablemente esté bastante seguro simplemente ejecutando el código (suponiendo que tenga buenas copias de seguridad por si acaso).

Una manera fácil de probar un DELETE, UPDATEo INSERTes cambiarlos a SELECT y ejecutarlos, luego confirmar que se devuelve el número y tipo de filas que espera.

Puede pensar que no necesita probar SELECTs porque en realidad no cambian ningún dato. Sin embargo, está ejecutando el código por una razón, ¿verdad? Supongamos que está investigando para su gerente, quien a su vez entregará estos datos a su gerente y así sucesivamente. Usted prueba para asegurarse de que no está obteniendo los datos incorrectos (o bloqueando a otros para que no recopilen sus datos).

Consultas ad hoc que hacen referencia / afectan los datos del sistema

Esta es posiblemente la única excepción a la regla "probar todo". Está ejecutando consultas de información sobre los datos del sistema. Lo importante aquí es recuperar los datos que espera. Si la consulta es algo simple (consultar una vista del sistema), entonces probablemente esté bien siempre que haya verificado lo que realmente significan las vistas / columnas. Si la consulta es compleja (por ejemplo, presionar 3 o 4 vistas del sistema con los cálculos en las columnas devueltas), entonces es posible que desee ejecutar algunas pruebas solo para asegurarse de que va a recuperar los datos que espera.

Resumen

En resumen, sí, quieres probar todo. Si es lo suficientemente importante para que lo escriba y lo ejecute, entonces es lo suficientemente importante como para que lo pruebe. Sin embargo, eso no significa que deba pasar una enorme cantidad de tiempo probando cada rama de cada línea de código. Pero se necesita hacer algún nivel de prueba.

Las pruebas unitarias automatizadas son tu amigo aquí. Con el advenimiento de DevOpsy Continuous Integrationverá más y más aplicaciones y métodos de prueba rápida y fácil de su código. Por supuesto, eso requiere tener un buen entorno de prueba y datos para acompañarlo, pero esa es una discusión completamente diferente.

Kenneth Fisher
fuente
4

Sé lo que sientes, tengo 3 años trabajando con MySQL, y en mi caso siempre pruebo las consultas DML que pueden modificar o romper cualquier información en cada tabla / base de datos / replicación esclava.

Siempre es la forma más segura de probar su consulta antes de ejecutarla.

No hay forma de saber si su consulta puede poner en riesgo su información de datos. La única forma es conocer la estructura y la configuración de la base de datos, para que pueda identificar fácilmente cuándo una consulta podría poner en riesgo sus datos confidenciales o no.

En DELETE, UPDATE, INSERT, siempre se debe tratar de utilizar SELECTprimero si no está seguro de cuál es la información que se va a modificar. En las selecciones, siempre intente usar el mismo tipo de datos para las condiciones que el tipo de datos de la columna, en algunos casos use EXPLAINpara la optimización.

oNare
fuente