What Do Contribution Guidelines Say About Software Testing?

Imagina los proyectos de software de código abierto como enormes y bulliciosas cocinas comunitarias. Cualquiera puede entrar, tomar un cuchillo y empezar a picar verduras (escribir código) para ayudar a cocinar una mejor comida. Pero para que la cocina funcione sin problemas, los chefs principales (los mantenedores del proyecto) dejan un Libro de Reglas sobre el mostrador. Este Libro de Reglas le dice a los nuevos ayudantes cómo lavarse las manos, dónde encontrar los ingredientes y cómo entregar sus verduras picadas sin arruinar la sopa.

Este documento es como un equipo de investigadores que entró en 200 de estas famosas cocinas comunitarias (específicamente aquellas que usan los lenguajes Python y JavaScript) para leer los Libros de Reglas y ver qué dicen realmente sobre las pruebas (testing).

En el mundo de la cocina, las "pruebas" son como probar el plato antes de servirlo para asegurarse de que no sepa a jabón. Los investigadores querían saber: ¿Los Libros de Reglas realmente enseñan a los nuevos ayudantes cómo probar la comida, o simplemente asumen que todo el mundo ya sabe cómo hacerlo?

Aquí está lo que encontraron, desglosado de forma sencilla:

1. La mayoría de las cocinas tienen una sección de "Probar" (pero no todas)

Los investigadores descubrieron que el 78% de las cocinas tenían una sección específica en su Libro de Reglas dedicada a probar (testing).

• ¿Dónde está? La mayoría de las veces (58%), está en un archivo llamado literalmente "CONTRIBUTING" (el manual de instrucciones principal). A veces está en un folleto separado y elegante (documentación externa), y rara vez está simplemente garabateado en el menú principal (README).
• La brecha: Alrededor del 22% de las cocinas no tenían instrucciones sobre las pruebas en absoluto. Si entrabas en esas cocinas, tendrías que adivinar cómo comprobar si tu comida estaba buena.

2. El desequilibrio del "Cómo hacer": Ejecutar vs. Escribir

Cuando los Libros de Reglas sí hablaban de probar, eran muy buenos en una cosa pero malos en otra.

• El "Cómo ejecutar" (83.5%): La mayoría de los Libros de Reglas decían claramente: "Aquí está el hechizo mágico (comando) para probar toda la olla". Es como decir: "Presiona este botón para comprobar el sabor".
• El "Cómo escribir" (37%): Muchos menos Libros de Reglas explicaban cómo crear una nueva prueba de sabor. Es como decir: "Presiona el botón", pero no enseñarte cómo fabricar una cuchara nueva o cómo saber qué es un sabor "malo".
• El resultado: Los ayudantes saben cómo comprobar la comida existente, pero a menudo se quedan adivinando cómo crear sus propias pruebas para los nuevos ingredientes que han añadido.

3. El problema de la "Pirámide de Pruebas"

En el software, existen diferentes niveles de pruebas, como diferentes tipos de pruebas de sabor:

• Pruebas Unitarias (71%): Estas son como probar un solo ingrediente (por ejemplo, "¿Sabe dulce esta zanahoria?"). Los Libros de Reglas hablaban mucho de esto.
• Pruebas de Integración (20.5%): Estas son como probar cómo funcionan la zanahoria y la cebolla juntas en la olla. Los Libros de Reglas mencionaban esto rara vez.
• Pruebas de Extremo a Extremo / End-to-End (15.5%): Estas son como probar la comida final, totalmente cocinada, para ver si todo el plato funciona. Los Libros de Reglas casi nunca hablaban de esto.

La Metáfora: Los chefs están muy preocupados por si las zanahorias saben bien, pero rara vez les dicen a los ayudantes cómo comprobar si todo el estofado se va a quemar o si los sabores se mezclan bien.

4. Las "Armas Secretas" faltantes

Los investigadores también buscaron consejos de cocina avanzados que ayudan a que las pruebas sean más fáciles y fiables:

• Simulación / Mocking (9.5%): A veces, no puedes probar el agua de mar real en tu sopa; tienes que usar un salero falso para simularlo. Esto se llama "mocking". Solo 1 de cada 10 cocinas tenía instrucciones sobre cómo usar estas herramientas falsas.
• Cobertura / Coverage (25.5%): Esta es una tarjeta de puntuación que muestra qué parte de la receta fue realmente probada. Solo alrededor de una cuarta parte de las cocinas decía a los ayudantes qué puntuación debían intentar alcanzar.
• Mejores Prácticas (9%): Consejos generales como "Siempre prueba antes de servir" eran muy poco comunes.

La Conclusión

El documento concluye que, si bien la mayoría de los proyectos de código abierto quieren que sus ayudantes prueben su trabajo, las instrucciones que dejan atrás están desequilibradas.

Son excelentes diciendo: "Aquí tienes cómo ejecutar la prueba", pero suelen guardar silencio sobre:

• Cómo escribir una nueva prueba.
• Cómo probar interacciones complejas (integración).
• Cómo probar todo el sistema (extremo a extremo).
• Cómo usar herramientas avanzadas (mocking) o establecer metas de calidad (cobertura).

La idea clave: Si eres un nuevo ayudante en una de estas cocinas, es posible que sepas cómo presionar el botón de "probar", pero podrías quedarte solo para descubrir cómo crear realmente una prueba de sabor para tu nueva receta, o cómo asegurar que tu nuevo plato no arruine toda la comida. Los autores sugieren que los líderes de los proyectos necesitan escribir instrucciones más claras y completas para que los ayudantes no tengan que adivinar.