Quickcheck in Go?

789 views
Skip to first unread message

Aaron Schlesinger

unread,
Jul 26, 2014, 5:58:08 PM7/26/14
to golan...@googlegroups.com
Hi Everyone - 

I'm trying to build a QuickCheck / ScalaCheck like library for Go. I think property based testing would be especially valuable for many of the systems level programs being built in Go, and I also just find it fun to implement.

My problem so far is that I have to use interface{} everywhere (I aliased it to Any if you're reading the code.) For example, I built a Generator interface that generates interface{} types. I know and accept that Go doesn't have generics (and I did before I started building this thing) and I'm not asking for the feature here. Instead, I'm asking a few more specific (and I hope more constructive) questions:
  1. how can I make the Generator implementations better indicate what type they will generate?
  2. each LazyList will be homogeneous in its type. is there a better way to indicate that fact?
    1. if so, is there a good way to indicate its type?
  3. how (if at all) will go generate help with (1) or (2)?

Aaron Schlesinger

unread,
Jul 26, 2014, 6:16:35 PM7/26/14
to golan...@googlegroups.com
... and I forgot the link to my repo: github.com/arschles/gocheck

Henrik Johansson

unread,
Jul 26, 2014, 6:42:34 PM7/26/14
to Aaron Schlesinger, golang-nuts

What is not enough in the one supplied with Go?

http://golang.org/pkg/testing/quick/

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Aaron Schlesinger

unread,
Jul 26, 2014, 6:50:48 PM7/26/14
to golan...@googlegroups.com, arsc...@gmail.com
A few limitations that I see:
  1. It doesn't support the semantic concept of a property and, as a result, property composition.
  2. Similar to (1) it doesn't support the generator concept or generator composition. I think this and (1) are important for testing larger systems composed of larger data structures.
  3. The library doesn't seem to do shrinking. does anyone know for sure?
That all being said, I have plans to see if I can use testing/quick under the hood for generators.

Dmitry Vyukov

unread,
Jul 27, 2014, 5:46:49 AM7/27/14
to Aaron Schlesinger, golang-nuts
It would also be awesome to use the new testing.Coverage function to
do guided fuzzing:
http://tip.golang.org/pkg/testing/#Coverage

Aaron Schlesinger

unread,
Jul 28, 2014, 12:13:37 PM7/28/14
to golan...@googlegroups.com, arsc...@gmail.com
+1. anything that gets to the "answer" (proving the property wrong) faster

for now, I'm more concerned with figuring out a better way to make the API clear to people writing tests

Caleb Spare

unread,
Jul 28, 2014, 12:45:40 PM7/28/14
to Aaron Schlesinger, golang-nuts
Be aware that 'gocheck' is the name of one of the earliest and most
popular third-party testing packages for Go.

http://labix.org/gocheck

Aaron Schlesinger

unread,
Jul 31, 2014, 11:57:17 AM7/31/14
to golan...@googlegroups.com, arsc...@gmail.com
Yup, I'm aware. Thanks!

bodo.j...@leanovate.de

unread,
Feb 25, 2016, 9:28:16 AM2/25/16
to golang-nuts
I stumbled upon this myself and "testing/quick" was just not sophisticated enough.

So I started to port ScalaCheck myself: https://github.com/leanovate/gopter

There are still some loose ends but overall its already working.
Any feedback would be highly welcomed.
Reply all
Reply to author
Forward
0 new messages