test-check 2020-07-05

(I was unable to post on Jira, so I report here) in the docstring of tuple:

(def t (tuple gen/small-integer gen/boolean))
should be
(def t (gen/tuple gen/small-integer gen/boolean))

let's see if I still have commit rights

I do! it's fixed, thanks

👍 1

Yesterday I struggled with test.check’s API, I had to use a lot of internal functions and did not see a way to do otherwise. Here is my function:

(defn- decreasing-sizes-gen
  "Returns a generator of lazy sequence of decreasing sizes."
  [max-size]
  (#'gen/make-gen
    (fn [rng _]
      (let [f (fn f [rng max-size]
                (when-not (neg? max-size)
                  (lazy-seq
                    (let [[r1 r2] (random/split rng)
                          size (#'gen/rand-range r1 0 max-size)]
                      (cons size (f r2 (dec size)))))))]
        (rose/pure (f rng max-size))))))

#_(gen/sample (decreasing-sizes-gen 100) 1)

• I had to make my own #'gen/make-gen because gen/randomized is not public, • gen/lazy-random-states is not public either, • I did not find an easy way to recursively iterate between using a generated value and using it to feed a new generator.

I am under the impression that, since the public API cannot be complete for sure, make-gen and rng should be exposed to the users.

If one day I am writing a successor to test.check, I would build it based on that.

You can't do this with the sizing combinators?

sized and with-size, I think

One to get the size, the other to set them

then I would still need a way to build my lazy sequence

It won't be lazy; is that important?

in my case, I could live without, but in the general case, lazy sequence is something with zero support in test.check

I will keep my function as is, but I wanted to report the limitations I found.

Yes. Should be easier to add laziness now that the rng is immutable