working on a fix for ticket #212
rizsotto at gmail.com
Mon Jun 15 19:23:44 EDT 2009
here it comes the split version of QC tests.
Small changes I made:
- The properties are registered in the tests/suite.hs module, so they
are executed now.
- The main function reads arguments and passing them to the
test-framework. So, it can exercise them separately.
- Added -Wall ghc option in the suite cabal file.
Hope it's working for you!
On Sun, Jun 14, 2009 at 9:33 PM, Duncan
Coutts<duncan.coutts at worc.ox.ac.uk> wrote:
> On Wed, 2009-05-13 at 22:32 +0200, Laszlo Nagy wrote:
>> Hi All,
>> Trying to create unit test suite.. work in progress. Comments are more
>> than welcome!
> Hi Laszlo,
> I'd like to get your tests integrated, in addition to the ones Stephen
> added recently. We can sort out the framework to use after getting them
> in. I expect Stephen is right that in the end we should use
> test-framework so that we can handle QC and HUnit based tests. It also
> looks like a reasonable framework generally.
> However the first thing to do is to get your existing tests in. Can I
> ask you to make a couple minor organisational changes?
> Instead of one massive tests/Test/Properties.hs file containing all the
> tests for the Distribution/* modules, could we use one module of
> properties for each module we're testing?
> So for example you integrated the existing
> into your
> but perhaps we could do the reverse and split it out into
> That would make it much easier for someone to go and find the properties
> they're looking for. I realise that many tests will share the same
> utility functions and generators etc. That's fine. For example the
> Test.Distribution.System module would define the generator for the OS
> and Arch types which are needed eg in
> Test.Distribution.PackageDescription. So just import one in the other.
> For things which do not belong to a specific module, we can just use
> shared utility modules like the existing
> or any other name that seems appropriate.
>> I wrote simple properties like this, for all data type
>> > prop_parse x = x == parse $ display x
>> I did merged the existing QuickCheck test cases into one file. I found
>> it easier to reuse the generator functions for different types.
>> My findings:
>> - The System.Platform did not passed parse tests. The reason: both
>> System.OS and System.Arch allowed the dash character in the name. But
>> System.Platform text representation was concatenate the two strings
>> separated by a dash. So I just simple removed the dash from them.
>> Solved! ;)
> Great. Could that be made into a separate patch from the addition of the
> tests? The commit message can say exactly what you just said in
> explanation of the change.
>> - VersionRange does not passes parse tests, iff more than two ranges
>> is present. As far as I could see, the parse method is wired to handle
>> only two ranges. Not corrected, because found no good solution. Need
>> help on this!
> Right, currently the parser only allows one conjunction and no brackets.
> There's an open ticket to allow more general expressions.
> For the moment then it's ok for this test to fail. We can expect it'll
> be fixed when ticket #484 is completed.
>> - Package.Dependency also not passes parse tests. (It is depend on
>> VersionRange success.)
>> - Compat.ReadR gather property is obsolete and does not compile. Can't
>> figure it out how could I rewrite it. Need help!
> Easy solution! The gather function is not used. We can just remove
> it :-)
>> - PackageDescription does not passes simple parse test. I guess the
>> problem is with the test itself! ;) I used showPackageDescription
>> method to generate string representation of this type and parse it
>> back. I could not judge it is an expected behaviour or a bug. Need
>> some explanation.
> The showPackageDescription is totally borked. It really doesn't work at
> all. Again it's ok for the moment if this test just fails. I'll be
> motivation for someone to fix showPackageDescription.
More information about the cabal-devel