testing - serp - Organizando pruebas Haskell

test seo tags

Question

Así que estoy tratando de seguir la estructura sugerida de un proyecto Haskell , y tengo un par de problemas para organizar mis pruebas.

Para simplificar, comencemos con:

src/Clue/Cards.hs # defines Clue.Cards module
testsuite/tests/Clue/Cards.hs # tests Clue.Cards module

Por un lado, no estoy seguro de cómo nombrar el módulo en testsuite/tests/Clue/Cards.hs que contiene el código de prueba, y para otro, no estoy seguro de cómo compilar mi código de prueba para que pueda enlazar a mi fuente:

% ghc -c testsuite/tests/Clue/Cards.hs -L src
testsuite/tests/Clue/Cards.hs:5:0:
    Failed to load interface for `Clue.Cards'':
      Use -v to see a list of the files searched for.

Answer 1

Aquí hay otra forma:

Las pruebas unitarias de cada módulo se definen como una lista de prueba del final del módulo , con algún esquema de nombres consistente, como "tests_Path_To_Module". Creo que esto me ayuda a escribir pruebas, ya que no tengo que buscar otro módulo muy lejos en el árbol de fuentes, ni mantener sincronizadas dos jerarquías de archivos paralelos.

La lista de prueba de un módulo también incluye las pruebas de cualquier submódulo. El runTestTT runner de Hunit está integrado en la aplicación y se puede acceder a través de un comando de prueba . Esto significa que un usuario puede ejecutar las pruebas en cualquier momento sin una configuración especial. O si no le gustan las pruebas de envío en la aplicación de producción, use los indicadores de CPP y cabal para incluirlos solo en compilaciones de desarrollo, o en un ejecutable de corredor de prueba separado.

También hay pruebas funcionales, una o más por archivo en el directorio de tests/ , se ejecuta con shelltestrunner y algunas pruebas relacionadas con el proceso dev basadas en el archivo Makefile.

Answer 2

Para completar, vale la pena mencionar un enfoque muy fácil para proyectos pequeños a través de ghci -i . Por ejemplo, en tu caso,

>ghci -isrc:testsuite
ghci>:l Clue.Cards
ghci>:l tests.Clue.Cards

Answer 3

Personalmente, creo que un directorio ./src/ adicional no tiene mucho sentido para proyectos pequeños de Haskell. De grueso hay fuente, descargué el código fuente.

De cualquier manera (con o sin src), le sugiero que refactorice y tenga un directorio Clue y un directorio de Test :

./Clue/Cards.hs   -- module Clude.Cards where ...
./Test/Cards.hs   -- module Test.Cards where ...

Esto permite a GHCi + Test.Cards ver Clue.Cards sin argumentos adicionales o usar cabal. En ese sentido, si no usas cabal + banderas para construir opcionalmente tus módulos de prueba, entonces deberías investigarlo.

Otra opción, que uso en muchos de mis proyectos, es tener:

./Some/Module/Hierarchy/File.hs
./tests/someTests.hs

Y yo cabal install el paquete y luego ejecuto las tests/someTests.hs cosas. Supongo que esto sería molesto si mis paquetes fueran particularmente grandes y demasiado largos para instalar.

Answer 4

Uso el enfoque de Snap Framework para sus suites de prueba, que básicamente se reduce a:

1. Utilice un marco de prueba como haskell-test-framework o HTF

2. Nombre los módulos que contienen pruebas agregando .Tests al nombre del módulo que contiene la IUT, por ejemplo:

   module Clue.Cards where ... -- module containing IUT
   
   module Clue.Cards.Tests where ... -- module containing tests for IUT

3. Al usar espacios de nombres separados, puede poner sus pruebas en pruebas de carpeta de origen separadas tests/ , luego puede usar un objetivo de compilación de Cabal (ver también la cabal test -construir soporte de objetivo en versiones recientes de Cabal) para el conjunto de pruebas que incluye la carpeta fuente adicional en su configuración hs-source-dirs , por ejemplo:

   Executable clue
     hs-source-dirs: src
     ...
   
   Executable clue-testsuite
     hs-source-dirs: src tests
     ...

   Esto funciona, ya que ya no hay una colisión del espacio de nombres entre los módulos en su IUT y el banco de pruebas.