Una guía para principiantes sobre pruebas: manejo de errores en casos extremos

Al crear piezas de software complejas, independientemente del idioma, comienza a notar un patrón en sus hábitos de prueba. Los mismos problemas de apariencia similar surgirán en diferentes plataformas o proyectos. Independientemente de si está creando otra demostración simple de lista de tareas pendientes para una charla o diseñando un back-end completo para una puesta en marcha de PaaS, comienzan a surgir los mismos patrones genéricos.

Hay seis casos que deben probarse que arrojarán luz sobre una sorprendente cantidad de problemas. Estos no están destinados a ser completos, ni a un conjunto de pruebas completo propio. Más bien, son un subconjunto fácil de recordar de paradigmas de prueba comunes que pueden aplicarse a cualquier lenguaje, marco o entorno.

Estos casos son inmediatamente útiles en dos aspectos de las rutinas de codificación diarias: depurar problemas específicos a medida que surgen y en la creación del conjunto de pruebas para una base de código. Están pensados ​​para ser formas de prueba genéricas y abstractas que arrojarán luz sobre algunos de los problemas más comunes que enfrentan los desarrolladores junior.

Estos solo serán útiles de manera indirecta en la programación funcional. La programación funcional evita muchos de los tipos más simples de errores que se describen a continuación. De cualquier manera, es útil tener en cuenta este tipo de casos de límites abstractos, ya que proporcionan una barrera de seguridad contra las malas prácticas en el código.

Las seis pruebas son las siguientes:

  • Cero
  • Uno
  • Dos
  • Dos a máximo-1
  • max
  • máx. + 1

Aunque estos son casos límite, su valor está en lo que representan. Mientras se asegura de que sus pruebas cubran toda la funcionalidad de su programa, debe mantener sus pruebas simples con el menor estilo posible.

Cero

El cero se usa para significar cualquier forma de entrada nula, ya sea indefinida, nula, una matriz vacía o simplemente el número real 0. Podría decirse que la forma más común y simple de error es hacer referencia a un valor cero, y siempre vale la pena probarlo. Simplemente pruebe una función, un punto final o una carga con una entrada cero y verifique que se comporte como se espera.

Uno

Uno, como Zero, es la forma más básica de la prueba individual genérica. La función se prueba con la primera entrada normal válida. Esto es más útil para las pruebas de regresión. En futuras iteraciones del código, esta prueba indicará rápidamente si el programa (o proceso) está funcionando como se esperaba.

Una prueba le brinda una línea de base para el éxito, ya sea una autenticación exitosa en un extremo de administración, una carga de archivo válida o una modificación correcta de la matriz.

Dos

Dos no se trata simplemente de probar el índice de matriz 2, o si su algoritmo funciona con 2 entradas. También abarca lo que sucede cuando ejecuta el mismo código dos veces.

Si alguien hiciera una solicitud DELETE HTTP dos veces seguidas al mismo recurso, ¿qué sucede? Si la función de clasificación con un comparador personalizado se llama dos veces seguidas, ¿se comporta como se esperaba?

Dos es un número interesante, porque es la primera vez que un código válido que funciona cuando se llama una vez puede mostrar efectos secundarios en ejecuciones repetidas. Realice un pequeño cambio en las funciones que hemos probado anteriormente.

Todo se reduce a modificaciones de estado y comprensión del comportamiento de una función. Si todo lo que tenemos es el nombre de la función, entonces este código se comporta exactamente como se anticipó. Tienes una variable llamada 0, llamas a la función setVarToOne y luego afirmas que es igual a uno.

A primera vista, esto se comportó exactamente como se esperaba. Sin embargo, probarlo con la idea de Two en mente resaltaría problemas más profundos con el código. Lo probaría llamándolo dos veces y afirmando que en ambos casos, mVar es igual a 1.

Dos a máximo-1

Dos a máximo-1 es el control de cordura. Es muy similar a la prueba One, pero hay una diferencia sutil. Este debería ser un caso de uso promedio , no el más simple ni el más directo, ni el más fácil de leer. Solo un caso de uso promedio que quizás no sea particularmente simple, pero es bastante común .

Max

Max es bastante sencillo: simplemente prueba los límites de su aplicación, especialmente alrededor de constantes máximas definidas.

Si tiene una implementación de lista vinculada simple, puede imaginar que tiene un número aparentemente infinito de inserciones permitidas. En realidad, hay un límite superior, ya sea INT_MAX, la cantidad de descriptores de archivos que su sistema operativo puede tener abiertos o simplemente la cantidad de memoria o espacio en disco asignado para su programa.

En algunas circunstancias, Max puede parecer una prueba imposible porque no hay un máximo conocido para lo que sea que esté probando. Su objetivo en estos casos, sin embargo, es de otra naturaleza: realizar una prueba de estrés en su aplicación.

Por ejemplo, es posible que cierta parte de los datos enviados por el usuario se reduzca y pase a través de funciones hasta que alcance un bucle que haya definido. Si estos datos son, digamos, INT_MAX, es posible que su código tarde una cantidad considerable de tiempo en completarse. Peor aún, podría hacer que su código no se detenga. Estos pueden ser problemas sutiles que solo surgen una vez que su código entra en producción, por lo que es importante detectarlos durante la fase de prueba.

Máx + 1

Max + 1 es una prueba que se usa principalmente para verificar los estándares o reglas implementadas por el programador. Esto implica probar cualquier cosa hasta su límite teórico + épsilon.

Esto podría manifestarse como un problema de fuera de límites de matriz, un error de un error, un error de desbordamiento de enteros o cualquier otro tipo de problema que suceda cuando alcanza los límites de su función o programa.

Si tiene un tamaño máximo de carga de archivo de 2 MB, intente cargar un archivo de 2 MB + 1b de tamaño. Si tiene un límite en el número de entradas en un catálogo de usuario, asegúrese de que la verificación se realice tanto en el lado del cliente como enlado del servidor.

Conclusión

Como se mencionó anteriormente, esta no es una imagen completa de lo que deberían ser sus rutinas de depuración o prueba. Esto simplemente proporciona una línea de base sólida y genérica que debe trascender cualquier marco o conjunto de pruebas específico.

Las pruebas se ven comúnmente como casos límite o límite, pero pueden asomar su fea cabeza en lugares que no son inmediatamente obvios.