¿Cómo funciona las pruebas en Perl: qué módulos incorporados y de terceros existen para las pruebas, en qué se diferencian y qué prácticas de pruebas se utilizan ampliamente en proyectos Perl?

Respuesta

En Perl, tradicionalmente se utiliza un paquete de módulos para pruebas: Test::Simple, Test::More, así como marcos complejos como Test::Class, Test::Most. El básico es Test::More — proporciona un conjunto rico de funciones: verificación de igualdad, comparación de estructuras, pruebas de lanzamiento de excepciones, etc.

Clasificación de módulos populares:

• Test::Simple — para pruebas muy simples y iniciales;
• Test::More — estándar de facto para la mayoría de proyectos;
• Test::Exception, Test::Deep, Test::Warn — para comprobar aspectos adicionales (excepciones, estructuras anidadas, advertencias);
• Test::Class, Test::Class::Moose — enfoques orientados a objetos.

Ejemplo de prueba con Test::More:

use Test::More tests => 2;

is(2 + 2, 4, 'La suma funciona');
like('foo_bar', qr/foo/, 'Hay foo');

Mejores prácticas:

• Todos los módulos públicos deben tener pruebas automáticas en el directorio t/.
• No mezclar datos de prueba con el código de producción.
• Aplicar pruebas unitarias, de integración, y a veces pruebas basadas en propiedades.

Pregunta trampa

¿Se pueden escribir pruebas personalizadas en Perl sin usar módulos Test::*, solo utilizando las construcciones die/print? ¿Qué riesgos conlleva este enfoque?

Respuesta: Formalmente sí — se pueden escribir sus "pruebas", utilizando print y die para mostrar resultados. Sin embargo, en tal caso no se forma un enfoque correcto hacia la automatización: no se admiten integraciones TAP/CPAN, es difícil crear informes y analizar múltiples pruebas, y se complica la escalabilidad y mantenimiento de la base de pruebas.

Ejemplo de prueba fallida:

print 'Multiplicación ok
' if multi(2,3) == 6;
die 'FAIL' if multi(2,0) != 0;

Ejemplos de errores reales debido al desconocimiento de los matices del tema

---

Historia

En un viejo proyecto, las pruebas fueron escritas "manualmente" usando die y print. No fue posible integrar la construcción de módulos CPAN automáticamente — los scripts no devolvían estados claros, lo que hizo que los errores de las pruebas se pasaran por alto en los lanzamientos.

---

Historia

El intento de mezclar el uso de Test::Simple y Test::More sin considerar la estructura TAP (Test Anything Protocol) resultó en una salida incorrecta que afectó al sistema automático de pruebas. Fue necesario rediseñar la infraestructura de pruebas.

---

Historia

La falta de buena cobertura de pruebas con Test::Exception resultó en el paso por alto de varios errores en el manejo de datos de entrada: uno de los módulos no lanzaba correctamente excepciones, esto no se detectó durante la prueba, y el error llegó a producción.