Closed modocache closed 9 years ago
Yeah, it's an unintuitive implementation of the port of clojure's test.check (which also exhibits similar behavior). There is a maxSize parameter which allows you to tweak this. The side effect of setting it to a large value is when generating collections (which can be extremely expensive for large arrays of elements).
A short-term mitigation strategy is to up the default max size parameter. A longer way is to look into how to indicate when an integer generator is used for a collection (something that is slow), versus some thing less computationally expensive to generate (like numbers).
Also, the hold matcher seems correct.
Also, the hold matcher seems correct.
Awesome, thanks! :+1:
I tried writing a Nimble matcher for PBT. This was before I learned about PBTAssert--it might be better to use that instead. For the time being, can you see any problems with this?
Also, one thing that confused me about
PBTInteger()
was that it seemed to only generate numbers between-50
and50
. Is that intended (sorry if dumb question, still reading through source)? It was very unintuitive--as a property-based tester I think I'd expect far out numbers like-879,213
, etc.I like the idea of a Nimble matcher for PBT, but it should probably be packaged as a separate project. It can be distributed using CocoaPods or Git submodules & drag-and-drop into Xcode, like AshFurrow/Nimble-Snapshots..