patch applied (ghc): Initial foundation for quickcheck tests.
lemmih at gmail.com
Fri Mar 10 17:11:23 EST 2006
On 3/10/06, Simon Marlow <simonmar at microsoft.com> wrote:
> On 10 March 2006 13:04, Lemmih wrote:
> > On 3/10/06, Simon Marlow <simonmarhaskell at gmail.com> wrote:
> >> Having no idea how to use the testsuite is not an excuse for not
> >> using it! There's a pretty good README.
> > The README is 400 lines long! How can that be good?
> Well, you don't need to read it all, of course.
> GHC is a complex system, there are lots of things to test. I believe
> our test suite is a pretty good framework, but I'm open to ways to
> improve it.
> Just adding tests to the tree outside the test suite framework is the
> best way to ensure that your tests never get run. How can that be good?
> > There are no serious quickchecks in the testsuite. I found just one
> > entry that didn't test the standard libraries: "prop_silly xs = head
> > xs == head xs". Now how can that be when QuickCheck is so incredibly
> > useful?
> look in lib/Concurrent, eg. Chan001, MVar001.
Those aren't GHC tests. They test the standard library.
> > I want to test the core of GHC and I want a neat interface. Running
> > 'make' in the testsuite sprays garbage like a broken fire hose and
> > doesn't die when I hit C-c.
> The C-c thing is a problem, I agree. I usually use C-z followed by kill
> %. There's probably a fix for it, but it never annoyed me enough to
> look into it.
> You don't want to say 'make' in testsuite/tests/ghc-regress unless you
> want to run all the tests as many ways as possible. Usually you want to
> go into a subdir and say make, or something like 'make TEST=foo fast' to
> run a single test just one way.
Running 'make fast' in lib/Concurrent still generates tons of garbage
and provides no easy way of finding important failures. It's fast but
still has exactly the same problems as before.
> > I don't really want that (how can people spot important failures among
> > the hundreds of tests that fail every day?).
> That's a different problem, namely that we haven't gone through and
> cleaned up the bogus failures for a while, and some of the failures are
> there to remind us about real bugs.
I don't see the point of running tests when it's not easy to see if
> > I think QuickCheck is a great tool and I'd love to continue using it
> > in the way it was intended.
> Sure - but just put your quickcheck tests in the existing testsuite
> framework, that's all I'm asking. Maybe we need a better way to
> integrate QuickCheck tests, I'm all for that.
Okay, I'll move it.
More information about the Cvs-ghc