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 <[email protected]> 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 > [email protected] • http://www.joachim-breitner.de/ > Jabber: [email protected] • GPG-Key: 0x4743206C > Debian Developer: [email protected] > _______________________________________________ > ghc-devs mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
