Puntos clave
1. Las pruebas automatizadas son fundamentales para la evolución y escalabilidad del software
La adopción de pruebas automatizadas impulsadas por los desarrolladores ha sido una de las prácticas más transformadoras en la ingeniería de software en Google.
La prevención es clave. Las pruebas automatizadas evitan que los errores lleguen a producción y afecten a los usuarios. También respaldan la capacidad de modificar el software con confianza, lo que permite una iteración más rápida y una adaptación a las tecnologías y condiciones del mercado en evolución. A la escala de Google, incluso un pequeño porcentaje de fallos en las pruebas puede desperdiciar enormes cantidades de tiempo de ingeniería, lo que hace que la automatización sea crucial.
Mejora continua. Las pruebas automatizadas proporcionan retroalimentación inmediata a los desarrolladores, permitiéndoles detectar y corregir problemas temprano en el proceso de desarrollo. Este ciclo de retroalimentación rápida acelera el desarrollo y mejora la calidad general del código. Además, las pruebas automatizadas sirven como documentación viva, ayudando a los ingenieros a entender cómo se supone que debe funcionar el sistema y proporcionando ejemplos de uso adecuado.
Beneficios de las pruebas automatizadas:
- Detectan errores temprano
- Permiten cambios con confianza
- Apoyan una iteración más rápida
- Proporcionan documentación viva
- Escalan con el crecimiento de la base de código
2. Las pruebas efectivas equilibran diferentes tipos y alcances de pruebas
En Google, buscamos una mezcla de aproximadamente 80% de pruebas unitarias y 20% de pruebas de mayor alcance.
Estrategia de pirámide de pruebas. Google emplea un enfoque de pirámide de pruebas, con una base de numerosas pruebas unitarias pequeñas y rápidas, complementadas por menos pruebas de integración y aún menos pruebas de extremo a extremo. Esta estrategia equilibra la necesidad de retroalimentación rápida con una validación integral del sistema.
Consideraciones de tamaño y alcance. Las pruebas se clasifican por tamaño (pequeñas, medianas, grandes) y alcance (unitarias, de integración, de extremo a extremo). Las pruebas pequeñas se ejecutan en un solo proceso y son rápidas y deterministas. Las pruebas medianas pueden abarcar múltiples procesos, pero están limitadas a una sola máquina. Las pruebas grandes pueden abarcar múltiples máquinas y se utilizan para pruebas completas del sistema. Al considerar cuidadosamente el tamaño y el alcance apropiados para cada prueba, los equipos pueden optimizar tanto la velocidad como la exhaustividad.
Clasificación de pruebas:
- Tamaño: Pequeñas, Medianas, Grandes
- Alcance: Unitarias, Integración, Extremo a Extremo
Beneficios de las pruebas equilibradas: - Retroalimentación rápida de las pruebas unitarias
- Cobertura integral de las pruebas de integración y extremo a extremo
- Uso eficiente de los recursos de prueba
3. La mantenibilidad de las pruebas es crucial para la productividad a largo plazo
Las pruebas mantenibles son aquellas que "simplemente funcionan": después de escribirlas, los ingenieros no necesitan pensar en ellas nuevamente hasta que fallen, y esas fallas indican errores reales con causas claras.
Evitar pruebas frágiles. Las pruebas frágiles se rompen en respuesta a cambios no relacionados, drenando la productividad y la moral. Para prevenir esto, las pruebas deben escribirse contra APIs públicas en lugar de detalles de implementación. Este enfoque asegura que las pruebas fallen solo cuando hay cambios significativos en el comportamiento del sistema.
Pruebas claras y enfocadas. Cuando las pruebas fallan, es crucial que la causa sea inmediatamente aparente. Las pruebas claras tienen un único propósito bien definido y evitan probar múltiples comportamientos simultáneamente. Deben ser completas (contener toda la información necesaria) y concisas (libres de detalles irrelevantes).
Características de pruebas mantenibles:
- Enfocadas en APIs públicas
- Propósito claro
- Información completa
- Implementación concisa
Beneficios: - Reducción de la carga de mantenimiento
- Depuración más fácil
- Mejora de la productividad del desarrollador
4. Escriba pruebas contra APIs públicas para reducir la fragilidad
La forma más importante de asegurar que las pruebas no necesiten cambiar a menos que cambien los requisitos del sistema que se está probando es escribir pruebas que invoquen el sistema de la misma manera que lo harían sus usuarios.
Enfoque en APIs públicas. Probar a través de APIs públicas asegura que las pruebas validen el comportamiento del sistema desde la perspectiva del usuario. Este enfoque hace que las pruebas sean más resistentes a la refactorización interna y a los cambios, siempre que el contrato público permanezca igual.
Definiendo APIs públicas. El concepto de "API pública" puede variar dependiendo de la unidad que se esté probando. Puede incluir métodos, clases o paquetes enteros que están destinados a ser utilizados por otras partes del sistema. La clave es identificar el nivel de abstracción apropiado para cada unidad y probar a ese nivel.
Beneficios de probar APIs públicas:
- Reducción de la fragilidad de las pruebas
- Mejor alineación con las expectativas del usuario
- Refactorización interna más fácil
Consideraciones para identificar APIs públicas: - Uso previsto por otras partes del sistema
- Nivel de abstracción apropiado para la unidad
- Estabilidad a largo plazo de la interfaz
5. Esfuércese por tener pruebas invariables para minimizar la carga de mantenimiento
La prueba ideal es invariable: después de que se escribe, nunca necesita cambiar a menos que cambien los requisitos del sistema bajo prueba.
Tipos de cambios en el código. Comprender los tipos de cambios que ocurren en una base de código ayuda a escribir pruebas estables. Estos incluyen refactorizaciones puras, nuevas características, correcciones de errores y cambios de comportamiento. Idealmente, solo los cambios de comportamiento deberían requerir actualizaciones a las pruebas existentes.
Diseñando para la estabilidad. Para lograr pruebas invariables, enfóquese en probar comportamientos en lugar de detalles de implementación. Use dobles de prueba con moderación, prefiriendo objetos reales cuando sea posible para evitar especificar en exceso las interacciones. Las pruebas de estado (verificando el estado final) son generalmente más estables que las pruebas de interacción (verificando llamadas a métodos específicos).
Estrategias para pruebas invariables:
- Probar comportamientos, no implementación
- Usar pruebas de estado en lugar de pruebas de interacción
- Minimizar el uso de dobles de prueba
Beneficios: - Reducción del costo de mantenimiento
- Mayor confianza en la refactorización
- Mejora de la longevidad del conjunto de pruebas
6. Enfóquese en probar comportamientos en lugar de métodos
En lugar de escribir una prueba para cada método, escriba una prueba para cada comportamiento.
Pruebas impulsadas por el comportamiento. Un comportamiento es una garantía que un sistema hace sobre cómo responderá a las entradas en un estado dado. Enmarcar las pruebas en torno a comportamientos en lugar de métodos conduce a pruebas más claras y enfocadas que son más fáciles de mantener y entender.
Expresando comportamientos. Los comportamientos a menudo pueden expresarse utilizando declaraciones "dado-cuando-entonces". Este formato define claramente el estado inicial, la acción tomada y el resultado esperado. Al estructurar las pruebas de esta manera, los ingenieros pueden identificar y probar más fácilmente todos los escenarios relevantes.
Componentes de una prueba impulsada por el comportamiento:
- Dado: Estado inicial
- Cuando: Acción tomada
- Entonces: Resultado esperado
Ventajas: - Propósito de prueba más claro
- Más fácil identificar casos de prueba faltantes
- Más resistente a cambios en la implementación
7. Cultive una fuerte cultura de pruebas dentro de la organización
En Google, hemos descubierto que a veces es necesario persuadir a los ingenieros de que probar a través de APIs públicas es mejor que probar contra detalles de implementación.
Cambio cultural. Establecer una fuerte cultura de pruebas requiere un esfuerzo continuo y el apoyo del liderazgo. En Google, este cambio involucró iniciativas como clases de orientación para nuevos empleados, el programa Test Certified para mejorar las prácticas de prueba del equipo y la peculiar pero efectiva iniciativa "Testing on the Toilet" para difundir el conocimiento sobre pruebas.
Refuerzo continuo. Mantener una cultura de pruebas requiere un refuerzo constante a través de revisiones de código, discusiones en equipo y reconocimiento de buenas prácticas de prueba. Es importante demostrar el valor de las pruebas en términos de mejora de la productividad, calidad del código y reducción de costos de mantenimiento.
Estrategias para construir una cultura de pruebas:
- Programas de educación y capacitación
- Reconocimiento de buenas prácticas de prueba
- Integración de pruebas en el flujo de trabajo de desarrollo
Beneficios: - Mejora de la calidad del código
- Ciclos de desarrollo más rápidos
- Reducción de costos de mantenimiento
8. Aproveche la automatización y las herramientas para apoyar los esfuerzos de prueba
Utilizamos herramientas como clang-tidy (para C++) y Error Prone (para Java) para automatizar el proceso de hacer cumplir las reglas.
Aplicación automática. Las herramientas que verifican automáticamente errores comunes, violaciones de estilo y otros problemas pueden reducir significativamente la carga sobre los revisores humanos y detectar problemas temprano en el proceso de desarrollo. Estas herramientas pueden integrarse en el entorno de desarrollo y en las canalizaciones de integración continua.
Herramientas personalizadas. Google ha desarrollado herramientas personalizadas como TAP (Test Automation Platform) para apoyar sus esfuerzos de prueba a gran escala. Estas herramientas ayudan a gestionar la complejidad de ejecutar millones de pruebas a través de miles de cambios diariamente.
Tipos de herramientas de automatización:
- Herramientas de análisis estático
- Linters
- Sistemas de integración continua
- Ejecutores de pruebas personalizados
Beneficios de la automatización: - Aplicación consistente de reglas
- Detección temprana de problemas
- Reducción de la carga cognitiva sobre desarrolladores y revisores
9. Equilibre el juicio humano con las pruebas automatizadas para una garantía de calidad integral
Las pruebas automatizadas no son adecuadas para todas las tareas de prueba.
Enfoques complementarios. Si bien las pruebas automatizadas forman la base de los esfuerzos de garantía de calidad de Google, ciertos aspectos de la calidad del software aún requieren juicio humano. Esto incluye evaluar la experiencia del usuario, detectar vulnerabilidades de seguridad complejas y realizar pruebas exploratorias para descubrir problemas inesperados.
Involucramiento humano dirigido. Al automatizar la mayoría de las tareas de prueba, los evaluadores humanos pueden centrarse en áreas donde su creatividad e intuición aportan más valor. Esto podría incluir evaluar la calidad de los resultados de búsqueda, evaluar la calidad de audio y video, o buscar fallas de seguridad complejas.
Áreas que se benefician del juicio humano:
- Evaluación de la experiencia del usuario
- Pruebas de seguridad complejas
- Pruebas exploratorias
- Evaluaciones cualitativas (por ejemplo, calidad de audio/video)
Mejores prácticas: - Automatizar pruebas repetitivas y bien definidas
- Reservar el esfuerzo humano para tareas de alto valor y que requieren juicio
- Utilizar pruebas exploratorias para complementar las pruebas automatizadas
Última actualización:
Reseñas
Ingeniería de Software en Google recibe en su mayoría críticas positivas, con una calificación promedio de 4.2/5. Los lectores valoran las perspectivas sobre las prácticas y la cultura de ingeniería de Google. Muchos encuentran útil la cobertura de temas como las revisiones de código, las pruebas y los cambios a gran escala. Algunos critican su enfoque centrado en Google y la falta de detalles prácticos para empresas más pequeñas. El libro es elogiado por su exhaustiva exploración de los principios de la ingeniería de software, aunque algunos capítulos son considerados menos atractivos. En general, se recomienda tanto para ingenieros experimentados como para aquellos que son nuevos en el campo.