Flujo de trabajo de pruebas de Haskell

Acabo de comenzar un nuevo proyecto de Haskell y quería configurar un buen flujo de trabajo de prueba desde el principio. Parece que Haskell tiene muchas herramientas de prueba excelentes y únicas y muchas formas diferentes de integrarlas.

He mirado en:

• HUnit
• Comprobación rápida
• press de banca
• HPC
• complejidad

Todos parecen funcionar muy bien en sus dominios, pero estoy buscando un enfoque integral para las pruebas y me preguntaba qué ha funcionado bien para otras personas.

Obtener las pruebas unitarias, la cobertura de código y los puntos de referencia correctos se trata principalmente de elegir las herramientas adecuadas.

• test-framework proporciona una ventanilla única para ejecutar todos sus casos de prueba de HUnit y propiedades QuickCheck , todo desde un solo arnés.
• La cobertura del código está integrada en GHC en forma de la herramienta HPC .
• Criterion proporciona una excelente maquinaria de evaluación comparativa

Usaré como ejemplo en ejecución un paquete que recién comencé a habilitar con pruebas unitarias, cobertura de código y puntos de referencia:

http://github.com/ekmett/speculation

Puede integrar sus pruebas y puntos de referencia directamente en su archivo de cabal agregando secciones para ellos y enmascarándolos detrás de banderas para que no hagan que todos los usuarios de su biblioteca tengan acceso (y quieran usar por sí mismos ) la versión exacta de las herramientas de prueba que ha elegido.

http://github.com/ekmett/speculation/blob/master/speculation.cabal

Luego, puede decirle a Cabal cómo ejecutar su suite de pruebas. Como la prueba de cabal aún no existe, ¡tenemos un estudiante trabajando en ella para el verano de código de este año! - El mejor mecanismo que tenemos es aquí cómo usar el mecanismo de gancho de usuario de cabal. Esto significa cambiar a una compilación 'personalizada' con cabal y configurar un testHook. Aquí puede encontrar un ejemplo de un testHook que ejecuta un programa de prueba escrito con test-framework y luego aplica hpc al perfil:

http://github.com/ekmett/speculation/blob/master/Setup.lhs

Y luego puede usar test-framework para agrupar las pruebas de QuickCheck y HUnit en un solo programa:

http://github.com/ekmett/speculation/blob/master/Test.hs

El archivo cabal tiene cuidado de activar -fhpc para habilitar las pruebas de cobertura de código, y luego el testHook en Setup.lhs ejecuta manualmente hpc y escribe su salida en su directorio dist.

Para la evaluación comparativa, la historia es un poco más manual, no hay una opción de "punto de referencia cabal". Puede conectar sus puntos de referencia en su gancho de prueba, pero me gusta ejecutarlos a mano, ya que Criterion tiene muchas opciones de informes gráficos. Puede agregar sus puntos de referencia al archivo de la cábala como se muestra arriba, darles banderas de compilación separadas, esconderlas detrás de una bandera de la cábala y luego usar Criterion para hacer todo el trabajo pesado:

http://github.com/ekmett/speculation/blob/master/Benchmark.hs

Luego puede ejecutar sus evaluaciones comparativas desde la línea de comando y obtener ventanas emergentes de KDE con resultados de evaluaciones comparativas, etc.

Dado que en la práctica estás viviendo en el Cabal de todos modos mientras desarrollas el código Haskell, tiene mucho sentido integrar tu cadena de herramientas con él.

Editar : el soporte de prueba Cabal ahora existe. Ver http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/developing-packages.html#test-suites

El enfoque es defendido en RWH ch 11 y en XMonad es aproximadamente:

• Indique todas las propiedades del sistema en QuickCheck
• Muestre la cobertura de la prueba con HPC.
• Confirme el comportamiento del espacio con la creación de perfiles de montón .
• Confirme el comportamiento de hilo / paralelo con ThreadScope .
• Confirme el comportamiento del microbenchmark con Criterion .

Una vez que sus principales invariantes se establecen a través de QuickCheck, puede comenzar a refactorizar, moviendo esas pruebas a invariantes de tipo.

Prácticas para apoyar sus esfuerzos:

• Ejecute una regresión QuickCheck simplificada en cada confirmación.
• Publica los detalles de la cobertura de HPC.

El paquete de marco de prueba es realmente asombroso. Puede integrar fácilmente las pruebas de HUnit y QuickCheck, y obtener ejecutables que ejecuten solo conjuntos específicos, basados ​​en indicadores de línea de comandos, con múltiples destinos de salida.

Sin embargo, las pruebas y la creación de perfiles son bestias diferentes. Para la generación de perfiles, configuré un ejecutable separado que enfatiza solo la sección que desea perfilar, y simplemente observando cuidadosamente los resultados de las compilaciones y ejecuciones de generación de perfiles (con -prof-auto-all para compilación y + RTS -p para un tiempo de ejecución bandera).

Para las pruebas, confío en las propiedades de HUnit y QuickCheck y utilizo Haskell Test Framework para recopilar todas las pruebas unitarias y todas las propiedades de QuickCheck automáticamente.

Descargo de responsabilidad: soy el desarrollador principal de Haskell Test Framework.