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