On 10 March 2006 13:04, Lemmih wrote:
> On 3/10/06, Simon Marlow <[EMAIL PROTECTED]> 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.
> 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.
> 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 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.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
