On Mon, Sep 28, 2009 at 4:42 AM, Gwern Branwen wrote:

On Sun, Sep 27, 2009 at 3:19 PM, Yusaku Hashimoto wrote: ...

...

Do you think I wasted times? Have you ever tried PDD? And has it worked? If you have experience with TDD, how do you think about PDD?

If you have any answers in any questions above, please tell me them. Thanks in advance.

Cheers -nwn

Here are some links from my Wikipedia article on QC which tout it:

Thanks for pointers. But I feel curious about in many QC examples (especially RWH's in your pointers), if property is falsifiable, they changes definition of the property, not implementation. And it annoys me because it seemed to almost duplicate its implementation. Am I misunderstanding? Cheers -nwn

On Mon, Sep 28, 2009 at 10:59 AM, Yusaku Hashimoto wrote:

After a few more investigations, I can say

QuickCheck does: - make easy to finding couter-cases and refactoring codes - make easy to test some functions if they have good mathematical properties - generate random test cases

But QuickCheck does *not*: - help us to find good properties

So what I want to know is "how to find good properties." Please let me know how do you find QuickCheck properties. There are so many tutorials or papers for using QuickCheck, but when I try to apply them to my programming, I often miss properties in my codes.

Cheers -nwn

I don't think there's any automated way to come up with good properties given a function; that seems tantamount to solving AI. One thing I've meant to do is look at checkers: http://hackage.haskell.org/package/checkers - which I understand includes a collection of lots of properties for various datatypes and classes. Presumably you could look through it for ideas ('ooh, I forgot that my results should monotonically increase!') or pick the module closest to what you're testing and steal as many of its properties as you can. -- gwern

Fantastic. If I understand correctly it inductively derives equations that hold for a set of examples. I am looking forward to see it in Haskell, who is working on the port? titto 2009/9/28 Emil Axelsson :

Not sure this is what you want, but I thought I'd mention "Formal Specifications for Free":

 http://www.erlang.org/euc/08/1005Hughes2.pdf

(I wasn't able to find a better link. That talk is for Erlang, but people are working on this for Haskell QuickCheck.)

/ Emil

Yusaku Hashimoto skrev:

...

After a few more investigations, I can say

QuickCheck does: - make easy to finding couter-cases and refactoring codes - make easy to test some functions if they have good mathematical properties - generate random test cases

But QuickCheck does *not*: - help us to find good properties

So what I want to know is "how to find good properties." Please let me know how do you find QuickCheck properties. There are so many tutorials or papers for using QuickCheck, but when I try to apply them to my programming, I often miss properties in my codes.

Cheers -nwn _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Pasqualino "Titto" Assini, Ph.D. http://quicquid.org/

On Mon, 2009-09-28 at 23:59 +0900, Yusaku Hashimoto wrote:

After a few more investigations, I can say

QuickCheck does: - make easy to finding couter-cases and refactoring codes - make easy to test some functions if they have good mathematical properties - generate random test cases

But QuickCheck does *not*: - help us to find good properties

So what I want to know is "how to find good properties." Please let me know how do you find QuickCheck properties.

This requires thought and practise. The properties are a partial formal description of what your program does. You have to decide what your program is supposed to do. There is no magic here. Sometimes you find that you adjust your properties to fit the program and sometimes adjust the program to fit the properties. To gain experience in thinking about properties of programs you probably want to look at books and articles and try examples. This is the kind of thing they teach in CS degrees. It is a matter of training yourself. Duncan

Ben Franksen wrote:

If it turns out that a precise spec is unwieldy (too complex) then this is a hint that maybe it is not a good abstraction.

Or your specification language is insufficient to describe it... (I don't know about anybody else, but I find that when I use QC, about 75% of the bugs reported are bugs in the spec, and only 25% are bugs in the thing I'm actually trying to test...)