En la búsqueda de un conjunto de pruebas robustas
Un problema común que veo en los paquetes de pruebas es la confusión sobre lo que cada prueba debe cubrir. Esta confusión a menudo conduce a pruebas que son demasiado amplias o demasiado enfocadas para lograr el objetivo de su creador. Cuando se escribe una prueba, es importante pensar en qué tipo de prueba será y las limitaciones que hacen que ese tipo de prueba sea eficaz. Tengo 4 categorías amplias de pruebas que tengo en mente para ayudar a enfocar mis pruebas.
Pruebas de unidad
También llamadas micro pruebas, las pruebas de unidad forman la base de cualquier buena estrategia de pruebas. Son pruebas que prueban una clase o método único de forma aislada de sus dependencias. Las pruebas dobles nos ayudan a aislar el código que se está probando y a hacer pruebas más enfocadas y expresivas. Una prueba que toca cualquier recurso externo como la base de datos, el sistema de archivos, un servicio web, etc. nunca es una prueba de unidad.
El propósito principal de las pruebas unitarias es validar que el sujeto sometido a prueba es funcionalmente correcto para las entradas y salidas esperadas. Además, las pruebas unitarias proporcionan documentación sobre cómo se espera que la clase funcione y sea utilizada por los consumidores.
Las pruebas de unidades buenas son rápidas, atómicas, aisladas, concluyentes, independientes del orden y ejecutadas automáticamente por el servidor de integración continua en cada confirmación del sistema de control de la fuente.
Los olores para las pruebas de unidad incluyen demasiada configuración, métodos de prueba largos, condiciones de carrera, dependencia de burlas estrictas, falta de integración del CI.
Pruebas de integración
Hay dos subcategorías primarias de pruebas que se llaman pruebas de integración.
Pruebas de dependencia externa
La primera categoría incluye pruebas que interactúan con una dependencia externa específica. Esto incluye las pruebas del código que se escribe dentro del sistema que interactúa con el componente externo. Los ejemplos incluyen pruebas de su capa de acceso a los datos, proxies de servicios web, proxies de sistemas de archivos, etc. Para proporcionar un valor real, estas pruebas deben ejercer la dependencia real. Por esa razón, a menudo requieren una mayor configuración y son más lentas de escribir y ejecutar que las pruebas unitarias, pero para tener confianza en un conjunto de pruebas, estas pruebas son absolutamente necesarias.
El propósito principal de estas pruebas de integración es validar el código que manipula el sistema externo. Además, estas pruebas pueden validar alguna porción del sistema remoto. Como ejemplo, consideremos un objeto de acceso a datos que se implementa en términos de un mapeador relacional de objetos con procedimientos almacenados en la base de datos. Si llama a Guardar, luego a Cargar y validar que el objeto recuperado es equivalente al objeto almacenado, ha probado su DAO, su mapeo OR, el o los procedimientos almacenados, la conexión de red, la cadena de conexión de la base de datos, el motor de la base de datos, el subsistema de evaluación de scripts de la base de datos, etc. Puede ver que estas pruebas ejercen un bloque de código e infraestructura más grande que las pruebas unitarias. Por esta razón, tienden a ser más frágiles y propensas a romperse.
Las buenas pruebas de integración validan las características del sistema externo que utiliza en su aplicación. No intentan cubrir el conjunto completo de funcionalidades, sino sólo validar que lo que necesitas funciona. Al igual que sus pruebas de unidad, estas pruebas deben ser atómicas, aisladas, concluyentes, independientes del orden, y ejecutadas automáticamente por el servidor de integración continua tan a menudo como sea razonable. También quieres que sean lo más rápidas posibles, pero ten en cuenta que nunca serán tan rápidas como tus pruebas de unidad.
Los olores de estas pruebas incluyen demasiada configuración, métodos de prueba largos, condiciones de carrera, dependencia de cualquier doble de prueba, falta de integración continua.
Pruebas del sistema parcial no enfocado
La segunda categoría de pruebas de integración son las que dependen de más de uno de sus propios componentes. Son pruebas que generalmente se confunden en cuanto a su papel. JB Rainsberger dio una excelente charla sobre estas pruebas que puedes ver aquí en InfoQ: Las pruebas de integración son una estafa.
Pruebas de aceptación
Las pruebas de aceptación a menudo se pasan por alto, pero son fundamentales para un conjunto de pruebas sólido. Estas son pruebas que ejecutan toda su pila; con la posible excepción de la interfaz de usuario. Para ser claros, esto significa no usar dobles de prueba de ningún tipo. Usted puede elegir pasar por alto la interfaz de usuario y adjuntarla en la capa de aplicación o en la API justo debajo de la interfaz de usuario. Estas pruebas complementan las pruebas de unidad e integración. Mientras que las pruebas de unidad e integración validan la corrección en lo pequeño, estas pruebas validan la composición correcta de sus bloques de construcción. Las pruebas de aceptación se escriben a menudo, pero no siempre, utilizando herramientas diferentes a las utilizadas en las pruebas de unidad e integración.
El propósito principal de estas pruebas es validar cosas como el cableado de los componentes, la integración de la pila de aplicaciones, los casos de uso básico/ historias de usuarios, el rendimiento del sistema y la estabilidad general de la aplicación. Es probable que estas pruebas sean las menos frecuentes, ya que su ejecución llevará bastante tiempo y pueden requerir una configuración extensa (aunque automatizada).
Las pruebas de buena aceptación pueden ser comprendidas por un usuario y están escritas en términos comunes a la empresa.
Los olores para las pruebas de aceptación incluyen el intento de validar cada camino a través del sistema.
Pruebas de la interfaz de usuario
Estas son pruebas que manipulan su aplicación de la forma en que lo haría el usuario. En teoría, se puede probar sólo la interfaz de usuario de esta manera, pero en la práctica, esto significa más a menudo que estas pruebas ejercitan toda la pila de la aplicación. Escribir pruebas de UI a menudo requiere herramientas especiales para manipular la aplicación. Estas son las pruebas más frágiles, quebradizas y costosas para escribir y mantener. También son las más lentas de ejecutar. A menudo es mejor usar estas pruebas sólo para validar que la aplicación es navegable, no se cae y tiene todas sus dependencias cumplidas.
Las buenas pruebas de UI son simples y de alcance limitado.
Los olores para las pruebas de UI incluyen fallas inconsistentes, probando la corrección de la aplicación.
Mejorando constantemente
Hay muchas maneras de clasificar las pruebas. Encuentro que estas 4 categorías me ayudan a enfocar mis pruebas y construir un conjunto de pruebas más rápido y confiable. ¿Qué técnicas utiliza para mejorar su conjunto de pruebas?
Categorías: artesaníaTags: testing, clean code