Unit tests for GHC code?

[Richard Eisenberg]

Let me take a different slice at this question, inspired more by Joachim's subject line than his text: On a number of occasions I've wanted to write unit tests against a certain function or set of functions. The role inference algorithm is a prime example, but it's happened elsewhere, too. The testsuite only performs end-to-end testing. Sometimes it's easy/possible to build a test that gets at what I want, but sometimes it's very hard. (Case in point: I revised the varSetElemsKvsFirst function on a branch -- it's really hard to test that thoroughly in an end-to-end test!)

So, is there a way / does someone know how to make a way to do proper unit testing? The ability to do such tests is treated as a key virtue of (pure) functional programming, and yet we don't do it! :)

For my varSetElemsKvsFirst problem, I ended up copying the code to a new file, writing dummy data structures to get it to compile, and then ran unit tests. I fixed my bug, but there was no way to integrate the testing work into a regression test, sadly.

Any thoughts?

Thanks,
Richard

On Jan 29, 2014, at 4:58 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:

> Hi,
> 
> I am currently working on a piece of code (an analysis to solve #7994)
> where I’d like to make sure that my changes do not regress over what I
> had before. But I find it unnecessarily hard to write our usual
> test-case styles for them:
>      * I’d like to test against very small Core that does not involve
>        anything unnecessary. But it is hard to write Haskell that has,
>        when it hits my analysis, this shape. It requires lots of {-#
>        NOINLINE #-} and other tricks.
>      * To test the result, I either have to write a performance test,
>        but it is not always easy to come up with a program where the
>        gains are massive enough to become a reliable test. It is
>        possible, but work, and doing it maybe half a dozen times for
>        various inputs is tricky.
>      * Alternative, I can dump the Core and add that to the test cases.
>        But now other changes to the compiler can easily trigger my test
>        case failing.
> 
> So I thought about writing a test case that simply imports my module
> from the ghc library, generates artificial, minimal core, and checks the
> output for precisely what I want (in my case, some fields of the IdInfo
> of various binders).
> 
> I don’t see any examples for that in the test suite. Is that just
> because noone has done that before, or is there inherently bad about
> this approach that we do _not_ want to that?
> 
> Also, we don’t have a parser for Core, so I’ll have to build my syntax
> trees using the stuff from MkCore et al, right?
> 
> Thanks,
> Joachim
> 
> 
> -- 
> Joachim “nomeata” Breitner
>  mail at joachim-breitner.de • http://www.joachim-breitner.de/
>  Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0x4743206C
>  Debian Developer: nomeata at debian.org
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs