Oh hombre, esa es una muy buena pregunta. Para nombrar unos pocos:
- Escribir pruebas automatizadas que sean consistentes.
- Escribir pruebas que lo ayuden a encontrar la causa raíz cuando fallan (por ejemplo, las pruebas complicadas de punta a punta son malas ).
- Recibir alertas (y alertar a otros miembros del equipo) en el momento adecuado cuando fallan las pruebas.
- Mantener los datos “ficticios” en un estado coherente entre pruebas y entornos.
Así es como abordamos estos problemas de prueba comunes en Assertible:
- Idealmente, cada prueba es lo más pequeña posible y usa solo las dependencias necesarias.
- Utilizamos la menor cantidad posible de pruebas de extremo a extremo. Con eso quiero decir, trate de no confiar en pruebas de varios pasos para nuestro control de calidad y monitoreo automatizados. Escribimos un artículo expresando un poco más de nuestra opinión sobre esto, y por qué no debe confiar completamente en estas pruebas para detectar errores: 4 técnicas para reducir los errores de prueba de API y mejorar su automatización de control de calidad.
- Cuando las pruebas fallan, debe poder descubrir rápidamente 1) ¿Qué componente falló? 2) ¿Falló algún otro componente? Y 3) ¿Se alertó a la persona correcta de esta falla? Nuevamente, mantener las pruebas tan simples y aisladas como sea posible ahorra un montón de tiempo cuando surgen estas fallas.
- En Assertible, exigimos que cada prueba defina su propia “configuración” y “desmontaje” para crear y eliminar datos ficticios. Al hacer esto, sabemos que nuestras pruebas son herméticas y encapsulan completamente el comportamiento deseado. A diferencia de las pruebas complicadas que se basan en varios pasos anteriores que se han completado con éxito, esto es malo.
Creo que algunas de las otras respuestas aquí son geniales, pero en mi opinión, cuando sus pruebas están estructuradas correctamente, aisladas y enfocadas en componentes más pequeños, todo lo demás se vuelve mucho más fácil. Informar un error ahora significa que tiene un caso de prueba completamente aislado, las pruebas se documentan automáticamente con sus requisitos y se pueden ejecutar más rápido (simultáneamente) ya que no se basan en varios pasos anteriores para completar primero.
- ¿Cómo priorizan los desarrolladores de startups la cobertura de prueba y TDD?
- Cómo desarrollar aplicaciones webgl con Visual Studio
- ¿Web2py es adecuado para la creación rápida de prototipos / sitios web medianos y grandes?
- ¿Cómo pueden los empleados proteger sus derechos de autor para el software producido fuera del horario laboral?
- ¿Cuáles son las diferencias entre el sistema y el software y el programa en términos de análisis del sistema?
Recursos:
- Blog de pruebas de Google: Automatización de pruebas versus automatización de pruebas
- Blog de Martin Fowler (por Rouan Wilsenach): QA en producción
:: Cody Reichert
Cofundador de Assertible – QA para la Web