unit testing - test - Función de privacidad y pruebas unitarias Haskell

pruebas unitarias java

Question

¿Cómo manejas la visibilidad de las funciones y las pruebas de unidades en Haskell?

Si exporta todas las funciones en un módulo para que las pruebas de la unidad tengan acceso a ellas, se arriesga a que otras personas llamen a funciones que no deberían estar en la API pública.

Pensé en usar {-# LANGUAGE CPP #-} y rodear las exportaciones con un #ifdef :

{-# LANGUAGE CPP #-}

module SomeModule
#ifndef TESTING
( export1
, export2
)
#endif
where

¿Hay una mejor manera?

Answer 1

La convención habitual es dividir su módulo en partes públicas y privadas, es decir,

module SomeModule.Internal where

-- ... exports all private methods

y luego la API pública

module SomeModule where (export1, export2)

import SomeModule.Internal

Luego puede importar SomeModule.Internal en pruebas y otros lugares donde es crucial para obtener acceso a la implementación interna.

La idea es que los usuarios de su biblioteca nunca llamen accidentalmente a la API privada, pero pueden usarla si saben lo que están haciendo (depuración, etc.). Esto aumenta en gran medida la usabilidad de su biblioteca en comparación con la ocultación forzada de la API privada.

Answer 2

Para las pruebas, normalmente divide la aplicación en el archivo del proyecto de cabal , entre una biblioteca, el ejecutable de producción y un ejecutable de prueba que prueba las funciones de la biblioteca, por lo que las funciones de confirmación de prueba se mantienen separadas.

Para la visibilidad de la función externa, divide los módulos de la biblioteca entre la sección "módulos expuestos" y la sección "otros módulos".