Sean Leather wrote:
>
> My tests are making use of a nice console test runner I wrote that
> supports both HUnit and QuickCheck (and is extensible to other test
> providers by the user):
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/test-framework.
>
>
> The descri
Ketil Malde wrote:
> "Conal Elliott" <[EMAIL PROTECTED]> writes:
>
>> Thanks a bunch for these tips. I haven't used the flags feature of cabal
>> before, and i don't seem to be able to get it right.
>
> Another option might be to have the test command build via 'ghc
> --make' instead of Cabal -
Sean Leather wrote:
>
> How do folks like to package up QuickCheck tests for their
> libraries? In the main library? As a separate repo & package?
> Same repo & separate package? Keeping tests with the tested code
> allows testing of non-exported functionality, but can add quit
2008/9/10 Johannes Waldmann <[EMAIL PROTECTED]>:
>
>>> Has there ever been a discussion of typed, user-definable,
>>> user-processable source code annotations for Haskell?
>>
>> afair it was on haskell-prime list
>
> http://hackage.haskell.org/trac/haskell-prime/ticket/88
>
> if you can call that a
If I do foo and foo-test, then I would probably place foo-test on Hackage.
Alternatively, just give foo a pointer to the location of the foo-test darcs
repo location. But then it might not be easy for users to keep the versions
in sync.
On Wed, Sep 10, 2008 at 10:24 AM, Wolfgang Jeltsch <
[EMAIL
Am Dienstag, 9. September 2008 16:05 schrieb Conal Elliott:
> […]
> > > My current leaning is to split a package "foo" into packages "foo"
> > > and "foo-test"
> >
> > What benefit does this provide?
>
> It keeps the library and its dependencies small.
Do you publish foo-test on Hackage? If yes
Am Dienstag, 9. September 2008 15:46 schrieb Sean Leather:
> […]
> Testing non-exported functionality without exporting the test interface
> seems difficult in general. Is there a way to hide part of a module
> interface with Cabal? Then, you could have a 'test' function exported from
> each modul
Has there ever been a discussion of typed, user-definable,
user-processable source code annotations for Haskell?
afair it was on haskell-prime list
http://hackage.haskell.org/trac/haskell-prime/ticket/88
if you can call that a discussion :-)
signature.asc
Description: OpenPGP digital sig
Hello Johannes,
Wednesday, September 10, 2008, 9:39:15 AM, you wrote:
> Has there ever been a discussion of typed, user-definable,
> user-processable source code annotations for Haskell?
afair it was on haskell-prime list
btw, Template Haskell may be used for this purpose (although not in
porta
Jason Dagit wrote:
On the other hand, specifying tests was
as simple as starting a function name with "prop_" [...]
which of course reminds us of JUnit of the dark ages (up to 3.8),
before they finally used annotations to declare test cases.
Has there ever been a discussion of typed, user-d
2008/9/9 Sean Leather <[EMAIL PROTECTED]>:
>
>> My tests are making use of a nice console test runner I wrote that
>> supports both HUnit and QuickCheck (and is extensible to other test
>> providers by the user):
>> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/test-framework.
>
> The
2008/9/9 Conal Elliott <[EMAIL PROTECTED]>:
> Where do you like to place your tests? In the functionality modules? A
> parallel structure? A single Test.hs file somewhere?
The last time I had a chance to experiment with how to do this I used
a single Test.hs for the whole project and I think t
> My tests are making use of a nice console test runner I wrote that
> supports both HUnit and QuickCheck (and is extensible to other test
> providers by the user):
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/test-framework.
>
The description looks great! I might have to try it ou
> Thanks a bunch for these tips. I haven't used the flags feature of cabal
> before, and i don't seem to be able to get it right.
>
This is also my first time, so I'm not sure exactly what I'm doing right. ;)
I have:
>
> Flag test
> Description: Enable testing
> Default: False
>
> And I
2008/9/9 Conal Elliott <[EMAIL PROTECTED]>:
> Hi Sean.
>
> Thanks a bunch for these tips. I haven't used the flags feature of cabal
> before, and i don't seem to be able to get it right. I have:
>
> Flag test
> Description: Enable testing
> Default: False
>
> And I get "Warning: unamb.cab
"Conal Elliott" <[EMAIL PROTECTED]> writes:
> Thanks a bunch for these tips. I haven't used the flags feature of cabal
> before, and i don't seem to be able to get it right.
Another option might be to have the test command build via 'ghc
--make' instead of Cabal - this way, you can avoid mentio
Hi Sean.
Thanks a bunch for these tips. I haven't used the flags feature of cabal
before, and i don't seem to be able to get it right. I have:
Flag test
Description: Enable testing
Default: False
And I get "Warning: unamb.cabal: Unknown section type: flag ignoring...".
If I indent, I i
> How do folks like to package up QuickCheck tests for their libraries? In
>>> the main library? As a separate repo & package? Same repo & separate
>>> package? Keeping tests with the tested code allows testing of non-exported
>>> functionality, but can add quite a lot of clutter.
>>>
>>
>> I h
Thanks, Sean.
On Tue, Sep 9, 2008 at 3:46 PM, Sean Leather <[EMAIL PROTECTED]> wrote:
>
> How do folks like to package up QuickCheck tests for their libraries? In
>> the main library? As a separate repo & package? Same repo & separate
>> package? Keeping tests with the tested code allows test
> How do folks like to package up QuickCheck tests for their libraries? In
> the main library? As a separate repo & package? Same repo & separate
> package? Keeping tests with the tested code allows testing of non-exported
> functionality, but can add quite a lot of clutter.
>
I have QuickChec
On Tue, Sep 9, 2008 at 2:05 PM, Dougal Stanton <[EMAIL PROTECTED]> wrote:
> If they're in a separate package it's less easy to wire quickcheck
> tests into the commit procedure.
And by package there, I mean repo. Obviously ;-)
D
___
Haskell-Cafe mailin
2008/9/9 Conal Elliott <[EMAIL PROTECTED]>:
> How do folks like to package up QuickCheck tests for their libraries? In
> the main library? As a separate repo & package? Same repo & separate
> package? Keeping tests with the tested code allows testing of non-exported
> functionality, but can add
How do folks like to package up QuickCheck tests for their libraries? In
the main library? As a separate repo & package? Same repo & separate
package? Keeping tests with the tested code allows testing of non-exported
functionality, but can add quite a lot of clutter.
My current leaning is to s
23 matches
Mail list logo
