A diferencia de lo que sí se deben probar, es una pregunta importante para todos los equipos. Las pruebas son un medio para lograr un fin, y elegir cómo priorizar las pruebas de diferentes partes de tu base de código puede ser difícil.
La mejor manera de priorizar es según tu base de código y los objetivos de tu equipo. Sin embargo, es importante recordar que, si bien lleva poco tiempo y ancho de banda escribir muchas pruebas pequeñas (en la parte inferior de la pirámide de pruebas, como las pruebas de unidades) que tienen mucha cobertura de código, no necesariamente reducen el riesgo general para tu proyecto.
Puedes elegir qué probar primero si piensas en los casos de uso principales de tu aplicación, sitio web o biblioteca. Por ejemplo, puedes escribir pruebas de componentes sobre partes críticas de tu sitio, los componentes principales que respaldan la experiencia del usuario. Por ejemplo, los desarrolladores de un sitio que permite que los usuarios suban y administren datos de series temporales deberían imaginar y probar las diferentes formas en que un usuario podría realizar esas tareas.
Otro enfoque de priorización implica obtener la mayor cantidad de información. Si tienes una parte de carga "peligrosa", heredada o que admite carga de tu base de código de manera incorrecta y a nadie de tu equipo le gusta trabajar, puede ser útil compilar pruebas en torno a ella para que su comportamiento sea más coherente antes de ignorarla o refactorizarla para solucionar el problema. Piensa en esto como el andamiaje de un edificio que ya fue condenado, pero que aún alberga tu centro de datos.
Dimensiones
Ya presentamos el concepto de una pirámide de pruebas o alguna otra forma de prueba, pero estas solo presentan una dimensión de la prueba: una línea que va desde pruebas de unidades simples y de pequeño alcance hasta pruebas complejas y de amplio alcance (pruebas de unidades frente a pruebas de integración frente a pruebas de extremo a extremo).
Sin embargo, algunas de la lista larga de tipos de pruebas posibles no representan un nivel de complejidad, sino que representan objetivos o técnicas de prueba. Por ejemplo, las pruebas de humo son una categoría diferente de pruebas, que pueden ser de unidades, de extremo a extremo o de otro tipo, pero están diseñadas para brindarles a los verificadores una confianza general de que el proyecto que se está probando está en un estado válido. Las pruebas visuales también pueden ser útiles para aplicarlas a un componente pequeño o a todo tu sitio.
Tu base de código tendrá requisitos únicos. Por ejemplo, podría ser mucho más importante en tu base de código alinearse con una sola función y escribir diferentes tipos de pruebas para garantizar que funcione correctamente. Rara vez una función nueva que necesita pruebas es un solo componente, función o enfoque, y su impacto en el proyecto puede distribuirse ampliamente y a diferentes escalas.
Sus prioridades de pruebas también pueden depender de las necesidades de su empresa. Los sistemas altamente técnicos pueden requerir pruebas de unidades complejas para confirmar que un algoritmo único se desempeña correctamente, mientras que es probable que las herramientas muy interactivas se enfoquen en pruebas visuales o de extremo a extremo para confirmar que las entradas táctiles complejas generan la respuesta correcta.
Tu enfoque para las pruebas
Intenta enfocarte en probar los casos de uso de tu base de código, sin importar su escala. Imagina cómo el usuario podría usar cualquier parte de tu proyecto, que podría representar un solo componente, una función de nivel inferior o un caso de uso de alto nivel de extremo a extremo. (Esto también puede revelar deficiencias en tus abstracciones a cualquier escala si notas que la prueba no puede interactuar de forma prolija con el código en prueba).
Es importante que cada caso de prueba tenga un objetivo claramente definido. Las pruebas genéricas grandes pueden ser difíciles de manejar, al igual que en el código que no es de prueba.
Apartado del desarrollo basado en pruebas
El desarrollo basado en pruebas (TDD) es un enfoque único de prueba (ortogonal a la escala o a tipos) en el sentido de que implica escribir pruebas destinadas a fallar, al menos al principio. Esto puede aplicarse tanto a las pruebas manuales como a las automatizadas: describe los objetivos que te gustaría alcanzar, descubres qué falta en tu solución o código actual y usas la prueba fallida como guía para encontrar una solución.
Por supuesto, no es útil probar todas las situaciones posibles en una aplicación o un componente hipotéticos incluso antes de comenzar a compilarlos. TDD tiene su lugar, y puede ser útil a medida que tu base de código se vuelve más compleja.
El TDD también es una práctica recomendada para corregir errores. Si puedes codificar el caso de reproducción de un error, puedes colocarlo en una prueba automatizada que al principio falle. Una vez que corrijas el error, se aprobará la prueba, lo que te permitirá determinar si la corrección se realizó de forma correcta sin la confirmación manual.
Opaco versus caja transparente
Esto se refiere a la forma en que pruebas cualquier parte del sistema. Si es opaco, no podrás ver el interior, por ejemplo, cuando uses la interfaz pública de una clase, en lugar de inspeccionar sus componentes internos.
A menos que tengas una razón específica para no hacerlo, es mejor comenzar con las pruebas de caja opaca para que puedas diseñar pruebas en función de cómo se usan tus componentes y no distraerte con el funcionamiento de su funcionamiento interno. Si solo te basas en la interfaz "pública" de una ruta de código (no necesariamente es pública para los usuarios, sino tal vez para otras partes de tu código), puedes refactorizar y mejorar ese código, ya que la prueba detectará cualquier cambio.
Una forma de convertir tu código de "caja blanca" para que sea más opaco es agregar elementos configurables, como abstracciones para las dependencias del código o devoluciones de llamada para observar el estado, en lugar de que ese estado esté estrechamente vinculado a otros sistemas. Esto hace que tu código esté más separado y te permite proporcionar versiones de prueba. Como alternativa, puedes simular dónde interactúa tu código con otros sistemas.