51

How do you deal with function visibility and unit testing in Haskell?

If you export every function in a module so that the unit tests have access to them, you risk other people calling functions that should not be in the public API.

I thought of using {-# LANGUAGE CPP #-} and then surrounding the exports with an #ifdef:

{-# LANGUAGE CPP #-}

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

Is there a better way?

Ralph
  • 31,584
  • 38
  • 145
  • 282
  • Possible duplicate of https://stackoverflow.com/questions/34571/how-do-i-test-a-class-that-has-private-methods-fields-or-inner-classes – Raedwald Dec 14 '17 at 12:46

2 Answers2

77

The usual convention is to split your module into public and private parts, i.e.

module SomeModule.Internal where

-- ... exports all private methods

and then the public API

module SomeModule where (export1, export2)

import SomeModule.Internal

Then you can import SomeModule.Internal in tests and other places where its crucial to get access to the internal implementation.

The idea is that the users of your library never accidentally call the private API, but they can use it if the know what they are doing (debugging etc.). This greatly increases the usability of you library compared to forcibly hiding the private API.

shang
  • 24,642
  • 3
  • 58
  • 86
  • 2
    Will this affect inlining (compile-time optimizations)? Reading https://www.haskell.org/haskellwiki/Performance/GHC#Inlining it seems like it would... So you can either write unit tests or optimize? (please, somebody tell me that I'm wrong!) – tlo Jan 25 '15 at 21:14
  • 1
    If the concern is that the inline-once optimization will be disabled by this technique, note that you can still use explicit inlining to ensure that it happens. – Jules Jun 05 '17 at 02:00
  • 2
    For anyone trying to use this advice with Haskell-Stack, to make the `SomeModule.Internal` module, you need to create a suitable directory structure - see [this question](https://stackoverflow.com/questions/28193295/load-a-module-in-ghci-by-module-name-when-module-name-doesnt-match-file-name). – hnefatl Jan 03 '18 at 12:15
9

For testing you normally split the application in the cabal project file, between a library, the production executable, and a test-suite executable that tests the library functions, so the test assertion functions are kept apart.

For external function visibility you split the library modules between the "exposed-modules" section and the "other-modules" section.

AndrewC
  • 32,300
  • 7
  • 79
  • 115
Gabriel Riba
  • 6,698
  • 2
  • 17
  • 19
  • for reference here is an example of a cabal package for an executable, which is split in library and executable: http://www.haskell.org/cabal/users-guide/developing-packages.html#configurations – Emmanuel Touzery Apr 09 '13 at 14:30
  • Can the testsuite contain tests against modules in the `other-modules` section? Unit testing internals without exposing them to outside clients sounds highly desirable to me. – Blaisorblade Jun 15 '16 at 12:16
  • 3
    @Blaisorblade yes, the way for the test-suite to access modules from `other-modules` is to specify in the cabal file `hs-source-dirs: src, tests` for the test suite. In other words the `src` is also compiled in the test suite. The downside is that you then compile your source twice: the normal way, and then again for the tests. But that's the best way I know. – Emmanuel Touzery Jul 10 '17 at 15:50