You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polygene.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2015/04/10 01:40:15 UTC
QuickCheck instead of JUnit
Gang,
Sandro Martini is on the Zest PMC, but seems a bit concerned about creating
noise on the list. But he asked me privately if we should perhaps have a
closer look at QuickCheck and its derivatives.
What convinced me was the following presentation;
http://www.infoq.com/presentations/testing-techniques-case-study
And that John mentions at the end "a language needs lambdas, that's why it
hasn't been possible before Java 8" piqued my interest quite a bit.
Qi4j is heading to "Java 8"-only territory rather rapidly, so the question
now is; Is there a Java 8 implementation of QuickCheck already out there??
Because the QuickScala stuff just scares me to no end. In fact, the Erlang
one is to me a lot better.
For Qi4j, QuickCheck approach seems very very logical, and possibly
enormously beneficial, since it should be specification driven in the first
place. And with a specification for EntityStore or Indexing (both currently
naivly driven by simple unit tests) gives a multiplier effect as well!!
Anyone want to pick this up and do some research?
Cheers
--
Niclas Hedhman, Software Developer
Re: QuickCheck instead of JUnit
Posted by Sandro Martini <sa...@gmail.com>.
Just created:
https://issues.apache.org/jira/browse/ZEST-18
Be free to comment/rewrite my description in a better way / assign to
me or reassign ...
Bye,
Sandro
Re: QuickCheck instead of JUnit
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Apr 14, 2015 at 6:24 PM, Sandro Martini <sa...@gmail.com>
wrote:
> Zest-sandbox as a playing area in git could be the place, right ?
> Of course I ahve to better understand Zest codebase in next period.
>
The repositories are now empty, until IP clearance is completed. Then the
Github repos will be copied across and we are on the way.
> On developing code in Zest codebase, the standard approach is to
> develop a feature in a dedicated git branch, and then merge (if/when
> needed) ? Maybe some generic info on coding style for Zest developers
> could be useful, to simplify things to new comers ...
>
See http://qi4j.org/community/codebase.html and other documentation in
Community section.
> A dedicated JIRA issue could be good to start tracking this feature.
>
Good idea; https://issues.apache.org/jira/browse/ZEST
Last, next time I'll post directly (thanks to Niclas in the meantime) :-) .
>
New blood is always welcome.
--
Niclas Hedhman, Software Developer
http://zest.apache.org/qi4j <http://www.qi4j.org> - New Energy for Java
Re: QuickCheck instead of JUnit
Posted by Sandro Martini <sa...@gmail.com>.
Hi all and thank you very much for supporting my idea :-) ...
Currently I'm not so focused on Java 8 features because in last years
I was/am more interested in Scala and Groovy, so my first idea to use
something like ScalaCheck ( http://scalacheck.org/ ) but maybe in a
project like Zest could be out of primary interest ... I have little
knowledge but if you think that something like that could be useful I
could try to get some time and prototype something simple and then
see, ok ?
Zest-sandbox as a playing area in git could be the place, right ?
Of course I ahve to better understand Zest codebase in next period.
On developing code in Zest codebase, the standard approach is to
develop a feature in a dedicated git branch, and then merge (if/when
needed) ? Maybe some generic info on coding style for Zest developers
could be useful, to simplify things to new comers ...
On *Check libraries for Java, like Paul I didn't find a library that
seems actively developed so I don't have a strong idea on what chose
... but a secondary *Check project maybe could help to split that in
codebase, to change/evolve/remove as needed, with not so much impact
on main code base.
A dedicated JIRA issue could be good to start tracking this feature.
Last, next time I'll post directly (thanks to Niclas in the meantime) :-) .
Bye,
Sandro
Re: QuickCheck instead of JUnit
Posted by Paul Merlin <pa...@nosphere.org>.
[snip]
Very interesting topic Sandro, thanks for bringing that. The
presentation recalled me of past headaches I had and the QuickCheck
approach seems promising. I see it as fuzzing + specifications +
shrinking. That's the shrinking part that does the magic!
Browsing existing implementations (thanks Marcel for the links), we can
see that shrinking is not implemented in most of them [1,2,3]. I also
found what looks like an abandonned project : QC4J [4] (that name
remains me something..). No shrinking implementation either.
The only project that seems to have been down the shrinking road so far
is FunctionalJava [5].
[1] https://github.com/pholser/junit-quickcheck/issues/32
[2] Nothing about shrinking in https://bitbucket.org/blob79/quickcheck
[3] Shrinking mentioned in TODO as 'Simplification' http://www.jcheck.org/
[4] http://sourceforge.net/projects/qc4j/
[5]
https://functionaljava.ci.cloudbees.com/job/master/javadoc/fj/test/package-summary.html
Re: QuickCheck instead of JUnit
Posted by Marcel Offermans <ma...@luminis.nl>.
On 10 Apr 2015 at 13:45:16, Marcel Offermans (marcel.offermans@luminis.nl) wrote:
I’ll start by doing some research to see if anybody started on such an implementation yet.
Did some browsing and kept some notes on potentially interesting sites for this. I’m dumping it here in case it helps anybody else.
Some research about it on-line, with the goal of a) understanding how it works and b) finding a good Java implementation:
http://stackoverflow.com/questions/576901/have-you-used-quickcheck-in-a-real-project - especially the first answer is valuable
There is a Scala implementation called “ScalaCheck” http://www.scalacheck.org/
There is a Java library that supports ScalaCheck/QuickCheck: https://github.com/functionaljava/functionaljava / http://www.functionaljava.org/
Another implementation is: https://bitbucket.org/blob79/quickcheck
Three Java ports are mentioned here: http://stackoverflow.com/questions/22712961/what-is-the-difference-between-agitar-and-quickcheck-property-based-testing
https://bitbucket.org/blob79/quickcheck (as found above)
http://www.jcheck.org/ (on SF, not updated for 2 years now, 0.1 version)
https://github.com/pholser/junit-quickcheck/ looks more promising.
Blog entries, still need to read them:
http://theyougen.blogspot.nl/2010/11/alternative-test-approach-quickcheck.html
http://www.theoryinpractice.net/post/83902909195/quickcheckng
https://blog.srcclr.com/property-based-testing-for-java/
http://java.dzone.com/articles/property-based-testing-spock
https://www.uni-marburg.de/fb12/ps/teaching/ss11/sw-analysis/quickcheck.pdf (german, states that a combination of QuickCheck and Pex (C#) would be ideal)
https://weblogs.java.net/blog/editors/archives/2009/06/quickcheck_for.html
podcast: http://www.functionalgeekery.com/episode-10-paul-holser/ (the first half is more interesting than the last, to me at least)
Another Java implementation: http://yaqc4j.sourceforge.net/
Guice based: https://code.google.com/p/guickcheck/ …code seems very basic
Similar, related links:
http://www.bodden.de/clara/ - Clara (CompiLe-time Approximation of Runtime Analyses) is a novel research framework for the implementation of hybrid typestate analyses, which use static analyses to partially evaluate runtime monitors for typestate properties. — has plenty of docs on the site
Re: QuickCheck instead of JUnit
Posted by Marcel Offermans <ma...@luminis.nl>.
That’s a great presentation. It would be very worthwhile to have a Java 8 implementation of QuickCheck. So you can add me to the list of people who are interested in this (not just in Qi4j context, but for Java applications in general).
I’ll start by doing some research to see if anybody started on such an implementation yet.
Greetings, Marcel
On 10 Apr 2015 at 01:46:01, Niclas Hedhman (niclas@hedhman.org) wrote:
Gang,
Sandro Martini is on the Zest PMC, but seems a bit concerned about creating
noise on the list. But he asked me privately if we should perhaps have a
closer look at QuickCheck and its derivatives.
What convinced me was the following presentation;
http://www.infoq.com/presentations/testing-techniques-case-study
And that John mentions at the end "a language needs lambdas, that's why it
hasn't been possible before Java 8" piqued my interest quite a bit.
Qi4j is heading to "Java 8"-only territory rather rapidly, so the question
now is; Is there a Java 8 implementation of QuickCheck already out there??
Because the QuickScala stuff just scares me to no end. In fact, the Erlang
one is to me a lot better.
For Qi4j, QuickCheck approach seems very very logical, and possibly
enormously beneficial, since it should be specification driven in the first
place. And with a specification for EntityStore or Indexing (both currently
naivly driven by simple unit tests) gives a multiplier effect as well!!
Anyone want to pick this up and do some research?
Cheers
--
Niclas Hedhman, Software Developer
Re: QuickCheck instead of JUnit
Posted by Stanislav Muhametsin <st...@kapsi.fi>.
On 10.4.2015 15:36, Marcel Offermans wrote:
> On 10 Apr 2015 at 14:31:02, Stanislav Muhametsin (stanislav.muhametsin@kapsi.fi) wrote:
> I just watched the presentation and it was great, and addressed a lot of
> issues that are very familiar to me.
> I am interested into this (more specifically, whether there is or will
> be anything like that in C#), hopefully will get some time to research
> as well.
> From browsing through resources, there seems to be something similar (but not identical to QuickCheck) for C# called “Pex” [1] so maybe that’s worth looking into for you?
>
> Greetings, Marcel
>
>
>
> [1] http://research.microsoft.com/en-us/projects/pex/
>
>
>
Great hint, I'll check it out! Thanks a lot! :)
Re: QuickCheck instead of JUnit
Posted by Marcel Offermans <ma...@luminis.nl>.
On 10 Apr 2015 at 14:31:02, Stanislav Muhametsin (stanislav.muhametsin@kapsi.fi) wrote:
I just watched the presentation and it was great, and addressed a lot of
issues that are very familiar to me.
I am interested into this (more specifically, whether there is or will
be anything like that in C#), hopefully will get some time to research
as well.
From browsing through resources, there seems to be something similar (but not identical to QuickCheck) for C# called “Pex” [1] so maybe that’s worth looking into for you?
Greetings, Marcel
[1] http://research.microsoft.com/en-us/projects/pex/
Re: QuickCheck instead of JUnit
Posted by Stanislav Muhametsin <st...@kapsi.fi>.
On 10.4.2015 2:40, Niclas Hedhman wrote:
> Gang,
> Sandro Martini is on the Zest PMC, but seems a bit concerned about creating
> noise on the list. But he asked me privately if we should perhaps have a
> closer look at QuickCheck and its derivatives.
>
> What convinced me was the following presentation;
> http://www.infoq.com/presentations/testing-techniques-case-study
>
> And that John mentions at the end "a language needs lambdas, that's why it
> hasn't been possible before Java 8" piqued my interest quite a bit.
>
> Qi4j is heading to "Java 8"-only territory rather rapidly, so the question
> now is; Is there a Java 8 implementation of QuickCheck already out there??
>
> Because the QuickScala stuff just scares me to no end. In fact, the Erlang
> one is to me a lot better.
>
> For Qi4j, QuickCheck approach seems very very logical, and possibly
> enormously beneficial, since it should be specification driven in the first
> place. And with a specification for EntityStore or Indexing (both currently
> naivly driven by simple unit tests) gives a multiplier effect as well!!
>
> Anyone want to pick this up and do some research?
>
>
> Cheers
I just watched the presentation and it was great, and addressed a lot of
issues that are very familiar to me.
I am interested into this (more specifically, whether there is or will
be anything like that in C#), hopefully will get some time to research
as well.
Count me out from Java8 stuff though - currently my resources are not
enough for anything Java-specific. :(