HI Alex,
Many thanks for your response, it was very helpful. I see your point
about customizing the generator, and in fact the video in the link does
something sort of similar to what I am trying to. So yeah I'll figure it
out tomorrow :). Thanks again!
Dimitris
On 03/11/16 18:53, Alex Miller wrote:
On Thursday, November 3, 2016 at 1:12:39 PM UTC-5, Jim foo.bar wrote:
Hi everyone,
I'm starting to get familiar with clojure.spec, and in my very
first spec I needed to specify relationship between the args
themselves (similar to how :fn specs allow for specifying some
relationship between :args & :ret). Is that at all possible?
:fn is the best way to do this (specifying a relationship either
between args or between an arg and ret)
Here is my use-case for the sake of argument:
(defn extract
"Analogous to `clojure.core/get`, but returns a vector of
`[item-at-k, coll-without-k]`. For Sequential things <k> can be an
integer (the index), or a predicate. In case of a predicate, the
first item that satisfies it will be extracted." [k coll]
...)
The implementation is quite simple but irrelevant for my question
and therefore omitted. Here are some sample invocations:
(extract :a {:a 1 :b 2}) => [1 {:b 2}]
(extract :a #{:a :b}) => [:a #{:b}]
(extract 1 [:a :b :c]) => [:b [:a :c]]
(extract (partial = b) [:a :b :c]) => [:b [:a :c]] ;; same as above
(extract 3 [:a :b :c]) => [nil [:a :b :c]] ;; nothing found
And here is my attempt at spec-ing this:
(spc/def ::predicate (spc/fspec :args (spc/cat :x any?)
:ret boolean?))
(spc/fdef extract
:args (spc/cat :value (spc/alt :index nat-int?
;:key any? FIXME::predicate ::predicate )
:coll coll?)
:ret (spc/tuple any? coll?)
:fn (spc/or :some-found #(let [[e c] (:ret %)
arg-coll (-> %:args :coll)]
(and (some? e)
(> (count arg-coll)
(count c))))
:nil-found #(let [[e c] (:ret %)
arg-coll (-> %:args :coll)]
(and (nil? e)
(> (count arg-coll)
(count c))))
:not-found #(let [[e c] (:ret %)
arg-coll (-> %:args :coll)]
(and (nil? e)
(= arg-coll c))))
)
So, as you can probably see, there are 2 problems with this:
1) Even though, I've verified that ::predicate gens correct
predicates (via `s/exercise`), when i try to gen-test it, it finds
predicates which are causing `extract` to return something like
`[x (x)]` (where x can be anything). So, it seems that there exist
predicates that cause `extract` to find the item, but not remove
it from coll. This is something that i can't reproduce manually!
Is the info on the failing example in this case not sufficient enough
to determine the failing case? I think it's worth at least considering
the possibility that your code has a bug. :) Maybe the info is not
sufficient, but I can judge without seeing the output and the actual code.
2) You may have noticed a `FIXME` in the :args spec. I would like
to enumerate the 3 possible/logical types of `:value (nat-int? or
::predicate for sequentials, but `any?` for maps/sets).
I don't think it's a good idea to separate the nat-int? and any? cases
- I would just use any? in this case. The key here (and really
everywhere you're writing an arg spec) is to try to state the truth as
much as you can. The truth here is that anything can be a key (even
though there is an identifiable case where the keys happen to be ints).
If i uncomment what i currently have i can see that gen-testing
will eventually mix something that is not an index nor a
::predicate (e.g. a string) with something sequential, which is
not supposed to happen.
So basically I'm stuck with this. If i comment out the `:predicate
::predicate` entry, then it passes gen-testing, but actually it
has only really tested 1/3 of the possible intended usages. :( Ok,
you might say that integers are perfectly valid keys in maps or
elements in sets, and so perhaps one could claim that 2/3 have
been tested. Is there any way of fully spec-ing this fn, or should
i just stick to a good doc-string and manually crafted test-cases?
You should definitely spec it! But this is a case where a custom
generator is called for - in particular one that takes into account a
better model for the inputs to the function. Stu Halloway did a whole
screencast on this at
https://www.youtube.com/watch?v=WoFkhE92fqc and I would recommend
fully understanding that approach. The gist is that instead of
generating the key to find and the collection independently, you want
to instead create a model of multiple cases. When you're trying to
model the case where a key is found, don't generate it randomly -
instead generate the coll, and use one of its keys.
Hope that helped.
Thanks in advance - any feedback is greatly appreciated :)
Kind regards,
Dimitris
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+unsubscr...@googlegroups.com
<mailto:clojure+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
