working on a fix for ticket #212
Hi All, Trying to create unit test suite.. work in progress. Comments are more than welcome! http://sites.google.com/site/rizsotto/patches/cabal-ticket-212-v1.darcs-send As an easy start, I wrote unit tests with QuickCheck on the following files: Distribution/License.hs Distribution/Package.hs Distribution/Compiler.hs Distribution/System.hs Distribution/ModuleName.hs Distribution/PackageDescription.hs 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! ;) - 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! - 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! - 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. My problem is mainly how to run these tests? As unit tests they are pure, does not manipulate any files on disks, does not open socket or anything. (Michael Feathers use the unit test word as strict as this.) So, I expected to run them by anyone, who could compile the sources. #1 'cabal test' could be the best way to exercise them. But the user hook is so complicated for a simple 'compile and run'. Found others ignoring the arguments and call System.Cmd, execute _the compiler_. The compiler name is wired and dependencies also not visible enough, not to mention the extension handling. Basically compile by hand is against cabal! :) (Pro: the best way to invoke; Con: very hard to do) #2 Create testing flag in the cabal file, which enable an executable to be build. (Xmonad guys doing this way.) It compiles easy, developer need not worry about different compilers. Running the test can be done by hand (or darcs) or the test user hook can execute it. If the main product is a library, then it does not link against that, since the library is not installed. Instead developers specify the source dir and it recompiles the tested sources. (Pro: easy to do; Cons: does not test against library) #3 Create another cabal file. Roughly speaking it is same as #2. In my opinion it is suite best for functional tests. (Pro: easy to do; Cons: testing target must be installed first) #4 Use the QuickCheck script. Based naming convention this script runs through the sources, 'grep' the properties, and exec an interpreter to run them. (Pro: easy; Cons: interpreter name is wired in the script) #5 As a proposed long term solution: I might add a new parameter to the 'executable' region describe the target is a unit test. Compile (and run) it only on 'cabal test' invocation. (Con: It does not exists and might be hard to implement :)) Thanks for any help! Regards, Laszlo
Laszlo, I have done the same thing! I posted a patch that includes a simple test harness using the test-framework package, which allows QuickCheck and HUnit tests to be mixed. Would you consider using that instead, because my tests are HUnit-based? It is not integrated with 'cabal test', though. Here's my patch: http://upcycle.it/~blackh/cabal/cabal-ticket-89-v5.darcs-send Duncan Coutts is evaluating this patch for me at the moment. Steve Laszlo Nagy wrote:
Hi All,
Trying to create unit test suite.. work in progress. Comments are more than welcome!
http://sites.google.com/site/rizsotto/patches/cabal-ticket-212-v1.darcs-send
As an easy start, I wrote unit tests with QuickCheck on the following files:
Distribution/License.hs Distribution/Package.hs Distribution/Compiler.hs Distribution/System.hs Distribution/ModuleName.hs Distribution/PackageDescription.hs
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! ;) - 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! - 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! - 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.
My problem is mainly how to run these tests? As unit tests they are pure, does not manipulate any files on disks, does not open socket or anything. (Michael Feathers use the unit test word as strict as this.) So, I expected to run them by anyone, who could compile the sources.
#1 'cabal test' could be the best way to exercise them. But the user hook is so complicated for a simple 'compile and run'. Found others ignoring the arguments and call System.Cmd, execute _the compiler_. The compiler name is wired and dependencies also not visible enough, not to mention the extension handling. Basically compile by hand is against cabal! :) (Pro: the best way to invoke; Con: very hard to do)
#2 Create testing flag in the cabal file, which enable an executable to be build. (Xmonad guys doing this way.) It compiles easy, developer need not worry about different compilers. Running the test can be done by hand (or darcs) or the test user hook can execute it. If the main product is a library, then it does not link against that, since the library is not installed. Instead developers specify the source dir and it recompiles the tested sources. (Pro: easy to do; Cons: does not test against library)
#3 Create another cabal file. Roughly speaking it is same as #2. In my opinion it is suite best for functional tests. (Pro: easy to do; Cons: testing target must be installed first)
#4 Use the QuickCheck script. Based naming convention this script runs through the sources, 'grep' the properties, and exec an interpreter to run them. (Pro: easy; Cons: interpreter name is wired in the script)
#5 As a proposed long term solution: I might add a new parameter to the 'executable' region describe the target is a unit test. Compile (and run) it only on 'cabal test' invocation. (Con: It does not exists and might be hard to implement :))
Thanks for any help!
Regards, Laszlo
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Hi Steve,
I saw Your patch. The existing unit tests (on parsing) does not cover
enough all the cases, and instead write more by hand thought
QuickCheck could suite better for this job. And my findings prove me.
;) The test cases could be run by the test-framework without any
problem I guess. And I already tried it.. Based on the experience I
wrote the enumeration in my previous letter. (The test harness require
to install the Cabal first, and just after that it compiles against
Cabal. I think installation should not be a precondition, but accept
it, since I could not offer a better working solution.)
Regards,
Laszlo
On Wed, May 13, 2009 at 11:59 PM, Stephen Blackheath [to cabal-devel]
Laszlo,
I have done the same thing! I posted a patch that includes a simple test harness using the test-framework package, which allows QuickCheck and HUnit tests to be mixed. Would you consider using that instead, because my tests are HUnit-based?
It is not integrated with 'cabal test', though. Here's my patch:
http://upcycle.it/~blackh/cabal/cabal-ticket-89-v5.darcs-send
Duncan Coutts is evaluating this patch for me at the moment.
Steve
Laszlo Nagy wrote:
Hi All,
Trying to create unit test suite.. work in progress. Comments are more than welcome!
http://sites.google.com/site/rizsotto/patches/cabal-ticket-212-v1.darcs-send
As an easy start, I wrote unit tests with QuickCheck on the following files:
Distribution/License.hs Distribution/Package.hs Distribution/Compiler.hs Distribution/System.hs Distribution/ModuleName.hs Distribution/PackageDescription.hs
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! ;) - 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! - 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! - 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.
My problem is mainly how to run these tests? As unit tests they are pure, does not manipulate any files on disks, does not open socket or anything. (Michael Feathers use the unit test word as strict as this.) So, I expected to run them by anyone, who could compile the sources.
#1 'cabal test' could be the best way to exercise them. But the user hook is so complicated for a simple 'compile and run'. Found others ignoring the arguments and call System.Cmd, execute _the compiler_. The compiler name is wired and dependencies also not visible enough, not to mention the extension handling. Basically compile by hand is against cabal! :) (Pro: the best way to invoke; Con: very hard to do)
#2 Create testing flag in the cabal file, which enable an executable to be build. (Xmonad guys doing this way.) It compiles easy, developer need not worry about different compilers. Running the test can be done by hand (or darcs) or the test user hook can execute it. If the main product is a library, then it does not link against that, since the library is not installed. Instead developers specify the source dir and it recompiles the tested sources. (Pro: easy to do; Cons: does not test against library)
#3 Create another cabal file. Roughly speaking it is same as #2. In my opinion it is suite best for functional tests. (Pro: easy to do; Cons: testing target must be installed first)
#4 Use the QuickCheck script. Based naming convention this script runs through the sources, 'grep' the properties, and exec an interpreter to run them. (Pro: easy; Cons: interpreter name is wired in the script)
#5 As a proposed long term solution: I might add a new parameter to the 'executable' region describe the target is a unit test. Compile (and run) it only on 'cabal test' invocation. (Con: It does not exists and might be hard to implement :))
Thanks for any help!
Regards, Laszlo
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
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!
http://sites.google.com/site/rizsotto/patches/cabal-ticket-212-v1.darcs-send
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 tests/Test/Distribution/Version.hs into your tests/Test/Properties.hs but perhaps we could do the reverse and split it out into tests/Test/Distribution/License.hs tests/Test/Distribution/Package.hs tests/Test/Distribution/Compiler.hs tests/Test/Distribution/System.hs tests/Test/Distribution/ModuleName.hs tests/Test/Distribution/PackageDescription.hs 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 tests/Test/QuickCheck/Utils.hs 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. http://hackage.haskell.org/trac/hackage/ticket/484 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.)
Right.
- 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.
My problem is mainly how to run these tests?
Lets get the tests in first and then sort this out.
As unit tests they are pure, does not manipulate any files on disks, does not open socket or anything. (Michael Feathers use the unit test word as strict as this.) So, I expected to run them by anyone, who could compile the sources.
Yes, pure tests are preferable wherever possible.
#1 'cabal test' could be the best way to exercise them. But the user hook is so complicated for a simple 'compile and run'. Found others ignoring the arguments and call System.Cmd, execute _the compiler_. The compiler name is wired and dependencies also not visible enough, not to mention the extension handling. Basically compile by hand is against cabal! :) (Pro: the best way to invoke; Con: very hard to do)
Yeah the test hook is pretty much useless. We've got a design for an improved test system but it may be a while before we implement it. So that would be the long term solution, and where better to try it out that Cabal's own tests. In the mean time we can sort out something, even if it's a little hacky. I can do that bit. Duncan
hi Duncan,
here it comes the split version of QC tests.
http://sites.google.com/site/rizsotto/patches/cabal-ticket-212-v2.darcs-send
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!
Regards,
Laszlo
On Sun, Jun 14, 2009 at 9:33 PM, Duncan
Coutts
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!
http://sites.google.com/site/rizsotto/patches/cabal-ticket-212-v1.darcs-send
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 tests/Test/Distribution/Version.hs into your tests/Test/Properties.hs but perhaps we could do the reverse and split it out into tests/Test/Distribution/License.hs tests/Test/Distribution/Package.hs tests/Test/Distribution/Compiler.hs tests/Test/Distribution/System.hs tests/Test/Distribution/ModuleName.hs tests/Test/Distribution/PackageDescription.hs
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 tests/Test/QuickCheck/Utils.hs 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. http://hackage.haskell.org/trac/hackage/ticket/484 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.)
Right.
- 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.
hi Duncan,
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.
http://sites.google.com/site/rizsotto/patches/cabal-system.platform-fix.darc... This is a one line fix for the mentioned problem. Separated from the test cases. Regards, Laszlo
Hi All,
- 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. http://hackage.haskell.org/trac/hackage/ticket/484 For the moment then it's ok for this test to fail. We can expect it'll be fixed when ticket #484 is completed.
I'm trying to solve this as well. http://sites.google.com/site/rizsotto/patches/cabal-ticket-484.v1.darcs-send For a start I modified the disp method only. I wanted to see what output shall be parsed. Please review it.
compat :: VersionRange compat = betweenVersionsInclusive (Version {versionBranch = [2,0,1], versionTags = []}) (Version {versionBranch = [2,3], versionTags = []})
brackets :: VersionRange brackets = unionVersionRanges compat compat
From the test values above it makes the following:
*Test Distribution.Text> show $ disp compat ">=2.0.1 && <=2.3" *Test Distribution.Text> show $ disp brackets "( >=2.0.1 && <=2.3 ) || ( >=2.0.1 && <=2.3 )" If it is the right way to do, I'm going to write the parser for it. Regards, Laszlo
Hello again,
http://sites.google.com/site/rizsotto/patches/cabal-ticket-484.v2.darcs-send
implemented the parse method. It handles the parentheses as it
described in the ticket. Tested with the QC patch I sent earlier.
Regards,
Laszlo
On Tue, Jun 16, 2009 at 9:54 PM, Laszlo Nagy
Hi All,
- 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. http://hackage.haskell.org/trac/hackage/ticket/484 For the moment then it's ok for this test to fail. We can expect it'll be fixed when ticket #484 is completed.
I'm trying to solve this as well.
http://sites.google.com/site/rizsotto/patches/cabal-ticket-484.v1.darcs-send
For a start I modified the disp method only. I wanted to see what output shall be parsed. Please review it.
compat :: VersionRange compat = betweenVersionsInclusive (Version {versionBranch = [2,0,1], versionTags = []}) (Version {versionBranch = [2,3], versionTags = []})
brackets :: VersionRange brackets = unionVersionRanges compat compat
From the test values above it makes the following:
*Test Distribution.Text> show $ disp compat ">=2.0.1 && <=2.3" *Test Distribution.Text> show $ disp brackets "( >=2.0.1 && <=2.3 ) || ( >=2.0.1 && <=2.3 )"
If it is the right way to do, I'm going to write the parser for it.
Regards, Laszlo
Hi All,
I updated my patches related to the test suite.
http://sites.google.com/site/rizsotto/patches/cabal-ticket212.darcs
http://sites.google.com/site/rizsotto/patches/cabal-ticket484.darcs
http://sites.google.com/site/rizsotto/patches/cabal-system.platform-fix.darc...
Regards,
Laszlo
On Sun, Jun 14, 2009 at 9:33 PM, Duncan
Coutts
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!
http://sites.google.com/site/rizsotto/patches/cabal-ticket-212-v1.darcs-send
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 tests/Test/Distribution/Version.hs into your tests/Test/Properties.hs but perhaps we could do the reverse and split it out into tests/Test/Distribution/License.hs tests/Test/Distribution/Package.hs tests/Test/Distribution/Compiler.hs tests/Test/Distribution/System.hs tests/Test/Distribution/ModuleName.hs tests/Test/Distribution/PackageDescription.hs
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 tests/Test/QuickCheck/Utils.hs 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. http://hackage.haskell.org/trac/hackage/ticket/484 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.)
Right.
- 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.
My problem is mainly how to run these tests?
Lets get the tests in first and then sort this out.
As unit tests they are pure, does not manipulate any files on disks, does not open socket or anything. (Michael Feathers use the unit test word as strict as this.) So, I expected to run them by anyone, who could compile the sources.
Yes, pure tests are preferable wherever possible.
#1 'cabal test' could be the best way to exercise them. But the user hook is so complicated for a simple 'compile and run'. Found others ignoring the arguments and call System.Cmd, execute _the compiler_. The compiler name is wired and dependencies also not visible enough, not to mention the extension handling. Basically compile by hand is against cabal! :) (Pro: the best way to invoke; Con: very hard to do)
Yeah the test hook is pretty much useless. We've got a design for an improved test system but it may be a while before we implement it.
So that would be the long term solution, and where better to try it out that Cabal's own tests. In the mean time we can sort out something, even if it's a little hacky. I can do that bit.
Duncan
participants (3)
-
Duncan Coutts -
Laszlo Nagy -
Stephen Blackheath [to cabal-devel]