ScalaCheck User Guide

Really impressive. One more reason to go in scala learning. Thank you for this work!

thanks

This tool helped me find a lot of bugs. Test Case Minimisation is awesome.

think the definition of CounterSpecification.getCommand needs to be modified to:

def genCommand(s: State): Gen[Command] = Gen.oneOf(Inc, Dec, Get)

to be able to be catch the bug introduced in the demo.

I'm getting (what I think is) a strange output when using Gen & Prop.forAll. The ARG_0 that was printed out (-1) should never have been tested:

scala> import org.scalacheck.Gen import org.scalacheck.Gen

scala> import org.scalacheck.Prop import org.scalacheck.Prop

scala> val smallInteger = Gen.choose(100,200) smallInteger: org.scalacheck.GenInt? = Gen()

scala> val propSmallInteger = Prop.forAll(smallInteger)(n => n >= 0 && n <= 100) propSmallInteger: org.scalacheck.Prop = Prop

scala> propSmallInteger.check ! Falsified after 0 passed tests. > ARG_0: -1

I would have thought that the ARG's tested would have fallen into the range [100,200]. Was -1 actually tested, or another value and -1 is just an indication that something failed?

The reason I'm asking is because I have a significantly more complicated test than this example, and the ("Falsified") output from it is useless to help me find the failing test cases (since I know they're not -1 ...).

Thanks!

John, please see the following mail thread: http://groups.google.com/group/scalacheck/msg/b563f24c81b22291

/ Rickard

Really impressive! Just a minor note: The usage of the term "property" is a misnomer. It should really be named "predicate" because it's a function with zero or more input values which maps to a boolean value. In contrast a property is just a, well, property of an entity, often an object.

Thanks for your insightful comment Christian. "A property is just a, well, property...", that's really cleared up the terminology for me.

I have a question concerning the Command example given at the end. When I include this test in an sbt-Project (sbt 0.11) and run it via a property in a Properties object, the test sometimes fails (about every 4th time). I think this could be because the test is run in a multithreaded fashion and therefore the mutable state of the counter object is modified from several threads. If this is indeed the case, is it possible to run Command test only in a single threaded while keeping the multi-threaded setup for all properties of immutable objects and pure functions?

Here is my properties-object:

object CounterProps extends Properties("Counter") {
  property("specs") = CounterSpecification
}

When testing this via sbt, most of the time the test is successful, but on the odd occasion, I get something such as:

Falsified after 3 passed tests. COMMANDS: Dec, Get, Dec

Other command chains might lead to a failure as well.