olopez32 / ganeti

Automatically exported from code.google.com/p/ganeti
0 stars 0 forks source link

Enable haskel exports to be just visible for testing #535

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
In order to write fine(r)-grained unit tests for module-internal functions in 
Haskell, those functions need to be be exported by the module, although besides 
the tests, nothing should see/access them directly. It would be nice to have 
something like "visible for testing" for our haskell code. (Some kind of 
preprocessing maybe?)

Original issue reported on code.google.com by hel...@google.com on 24 Jul 2013 at 5:33

GoogleCodeExporter commented 9 years ago
Just FYI:

What I've seen other projects do is to use CPP defines, e.g.:

module A ( A.visibleFunction
#ifdef TEST
         , A.internalFunction
         , …
#endif
         ) where …

I think we discussed this briefly ~6 months ago, but at that point it was not a 
priority.

Original comment by iust...@gmail.com on 24 Jul 2013 at 6:58

GoogleCodeExporter commented 9 years ago
Yes, I remember that we talked about it. I actually found it in my (very old) 
notes and figured if I hadn't time to get to it in half a year, someone else 
might get to it earlier :)

Original comment by hel...@google.com on 25 Jul 2013 at 11:38

GoogleCodeExporter commented 9 years ago
commit d16e3ce40db7e046023373d25f1444614f74b721
Author: Jose A. Lopes <jabolopes@google.com>
Date:   Wed Sep 18 13:22:02 2013 +0200

    Optimize Haskell compilation

    The idea is to compile (on demand, that is, when necessary) each
    source file to a normal object file, a coverage object file, a
    profiling object file, and a test object file.  Also, a given Haskell
    binary is linked with the proper object files.  This is achieved with
    the following Makefile variables:

    Compilation modes (profiles):
    1. HPROFILE enables/disables profiling
    2. HCOVERAGE enables/disables coverage
    3. HTEST enables/disables 'TEST' preprocessor definition

    A few words on testing: testing means the problem described in issue
    535: https://code.google.com/p/ganeti/issues/detail?id=535.  With
    HTEST enable, ghc will be instructed to define the preprocessor
    definition TEST, for modules that use '#ifdef TEST'.

    Haskell binary targets fetch the proper dependencies.  They are also
    '.PHONY' targets so that 'make' does not check for the file timestamp
    and instead it will always call 'ghc --make ...'.  This is not a
    problem because 'ghc' with the '--make' flag only compiles the
    necessary object files.

    Signed-off-by: Jose A. Lopes <jabolopes@google.com>
    Reviewed-by: Michele Tartara <mtartara@google.com>

Original comment by jabolo...@google.com on 6 Nov 2013 at 3:35

GoogleCodeExporter commented 9 years ago
Reopening this, because with the current implementation, you can either have 
coverage or the test flag. This is not useful in some cases, since in 
particular in the tests you might want to use both, the '#ifdef TEST' defines 
and generate coverage files at the same time.

Original comment by hel...@google.com on 14 Nov 2013 at 9:05

GoogleCodeExporter commented 9 years ago
To fix this, we need to be able to combine compilation profiles, or at least be 
able to combine the HTEST profile with the others, which in turn requires 
generating suffixes according to the profile combination or, as suggested, to 
compile to a separate directory. 

Original comment by jabolo...@google.com on 14 Nov 2013 at 9:47

GoogleCodeExporter commented 9 years ago
I am removing myself from owner as the scenario changed considerably.

Original comment by jabolo...@google.com on 23 May 2014 at 1:46

GoogleCodeExporter commented 9 years ago
I've seen in many projects the following structure: For a module Xy we have

- module Xy.Internal contains all the code and exports everything
- module Xy just re-exports from Xy.Internal what should be public

This way it's possible to test the internals, and it's easy to check that 
production code doesn't use any internals.

Original comment by pud...@google.com on 23 May 2014 at 1:50