convert a custom test-suite to Cabal-test
Currently I am trying to convert the test suite in utility-ht to Cabal's new Testing feature. The documentation in http://www.haskell.org/ghc/docs/7.0.2/html/libraries/Cabal-1.10.1.0/Distribu... mentions the packages cabal-test-hunit, cabal-test-quickcheck1, and cabal-test-quickcheck2 but I cannot find them on Hackage. Will I be able to write a test-suite that works both with QuickCheck-1 and QuickCheck-2? So far I was able to write my Arbitrary instances and tests in a way that they can be run from both QuickCheck-1 and QuickCheck-2. Thus a single package cabal-test-quickcheck that provides a consistent interface to both QuickCheck versions would help me. I am unhappy about the naming PureTestable vs. ImpureTestable. As part of a fundamental package like Cabal it further fixes the ubiquitous confusion about purity in Haskell. I propose to rename as follows: ImpureTestable -> IOTestable PureTestable -> SimpleTestable or BoolTestable
On Sun, Mar 13, 2011 at 8:29 AM, Henning Thielemann
Currently I am trying to convert the test suite in utility-ht to Cabal's new Testing feature. The documentation in
http://www.haskell.org/ghc/docs/7.0.2/html/libraries/Cabal-1.10.1.0/Distribu... mentions the packages cabal-test-hunit, cabal-test-quickcheck1, and cabal-test-quickcheck2 but I cannot find them on Hackage.
The detailed test suite type is disabled in every released version of Cabal because we've been planning major changes to it for some time. Because of this, these packages were never released.
Will I be able to write a test-suite that works both with QuickCheck-1 and QuickCheck-2? So far I was able to write my Arbitrary instances and tests in a way that they can be run from both QuickCheck-1 and QuickCheck-2. Thus a single package cabal-test-quickcheck that provides a consistent interface to both QuickCheck versions would help me.
The hope is that once the library interface is finished, the QuickCheck author(s) would choose to support it directly. Then, you wouldn't need cabal-test-quickcheck{1,2} and you could write test suites that work with either version.
I am unhappy about the naming PureTestable vs. ImpureTestable. As part of a fundamental package like Cabal it further fixes the ubiquitous confusion about purity in Haskell. I propose to rename as follows:
I am also unhappy with the interface (and I wrote it!). We have known for a long time that we were going to change this, which is why it was never enabled in a released version of Cabal. I recently submitted a patch which greatly improves the detailed interface; this is one issue in particular that it addresses. That patch is not yet in the darcs repository for Cabal, but if you're going to develop a test suite for the detailed interface, I would recommend that you wait until it is, rather than develop against an obsolete interface. If you want to target released versions of Cabal, you could instead develop your test suite against the exitcode-stdio interface, which is available now. Thanks for your interest! -- Thomas Tuegel
On Sun, 13 Mar 2011, Thomas Tuegel wrote:
The hope is that once the library interface is finished, the QuickCheck author(s) would choose to support it directly. Then, you wouldn't need cabal-test-quickcheck{1,2} and you could write test suites that work with either version.
I would also prefer it this way.
I am unhappy about the naming PureTestable vs. ImpureTestable. As part of a fundamental package like Cabal it further fixes the ubiquitous confusion about purity in Haskell. I propose to rename as follows:
I am also unhappy with the interface (and I wrote it!). We have known for a long time that we were going to change this, which is why it was never enabled in a released version of Cabal.
But ImpureTestable is exported from the Cabal-1.10 that is shipped with GHC-7.0.2.
I recently submitted a patch which greatly improves the detailed interface; this is one issue in particular that it addresses. That patch is not yet in the darcs repository for Cabal, but if you're going to develop a test suite for the detailed interface, I would recommend that you wait until it is, rather than develop against an obsolete interface. If you want to target released versions of Cabal, you could instead develop your test suite against the exitcode-stdio interface, which is available now.
I prefer to convert my test-suites only once, thus I'll wait. When running 'cabal test' within a darcs test run, then darcs removes the entire directory after completing the tests. Thus I cannot see the log files. When running the test manually I see the output from the tests in the terminal.
On Sun, Mar 13, 2011 at 11:18 AM, Henning Thielemann
On Sun, 13 Mar 2011, Thomas Tuegel wrote:
I am also unhappy with the interface (and I wrote it!). We have known for a long time that we were going to change this, which is why it was never enabled in a released version of Cabal.
But ImpureTestable is exported from the Cabal-1.10 that is shipped with GHC-7.0.2.
It is, but if you write a test using "type: detailed-0.9" in the test-suite stanza, Cabal-1.10 will reject your .cabal file. -- Thomas Tuegel
On Mar 13, 2011 11:19 PM, "Henning Thielemann" < lemming@henning-thielemann.de> wrote:
On Sun, 13 Mar 2011, Thomas Tuegel wrote:
I recently submitted a patch which greatly improves the detailed
interface; this is one issue in particular that it addresses. That patch is not yet in the darcs repository for Cabal, but if you're going to develop a test suite for the detailed interface, I would recommend that you wait until it is, rather than develop against an obsolete interface. If you want to target released versions of Cabal, you could instead develop your test suite against the exitcode-stdio interface, which is available now.
I prefer to convert my test-suites only once, thus I'll wait.
_____________________________________________
cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
If you have a test suite that uses test-framework it can easily be changed to use the stdio-exitcode interface.
participants (3)
-
Henning Thielemann -
Johan Tibell -
Thomas Tuegel