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.