Fork me on GitHub
#clojure-spec
<
2020-06-11
>
jacklombard09:06:11

Do you all unit test specs?

Jivago Alves13:06:38

Never unit tested specs. But I'm using it as part of the test. I'd test it if I was going to release it as a library.

jacklombard13:06:36

for complex specs that i use to validate data, would like to know if the spec is right

avi14:06:04

That’s… interesting! Because I think I already think of specs as, more or less, akin to tests themselves.

avi14:06:05

I do of course sometimes find that a spec I’ve written turns out to not quite capture what I had in mind, or a requirement, etc… but I’ve done the same with “traditional unit tests” (i.e. example tests) …

Jivago Alves16:06:18

I use spec to help me to parse some data but I'm testing the function that does that. The fact I'm using a spec is just a implementation detail. At least, that was most of my use cases.

avi16:06:22

Ah, I see, yeah. That makes sense.

avi16:06:33

In that case, yes, I would probably write some example tests.

seancorfield18:06:14

My approach to developing complex Specs is to have a (comment ,,,) form under the Specs with expressions in it that I use to test validation, conformance, and generation.

seancorfield18:06:56

I also make sure to "test" each individual part of a Spec (so I can catch generation problems early -- debugging generation problems in a large Spec is no fun!).

misha15:06:15

can I express "this key is optional, but if is in map - that key has to be there too, " as s/keys out of the box? with some combination of :opt :req and or like (s/keys :req [(or :a/foo :a/bar)]) or something? Or should I s/and it?:

(s/and
      (s/keys :opt [:a/foo :a/bar])
      (fn [m]
        (let [present (partial contains? m)
              missing (complement present)
              ks [:a/foo :a/bar]]
          (or 
            (every? present ks)
            (every? missing ks)))))

Alex Miller (Clojure team)15:06:43

s/and'ing a predicate is prob best

misha15:06:36

is it s/and in spec2 for the same use case?

misha15:06:31

thank you

Alex Miller (Clojure team)15:06:26

yeah, I would do the same in spec 2

Alex Miller (Clojure team)15:06:52

or rather I would probably make 2 different s/selects for the same s/schema

👍 3
Alex Miller (Clojure team)16:06:01

s/keys is probably going away in spec 2

dev.4openID17:06:49

@alexmiller Over what time-frame are you anticipating spec 2 to come out?

Alex Miller (Clojure team)18:06:41

I’m deep in something else right now, but hoping to pop the stack back to that soon. Not sure, prob mostly gated in rework of function specs which rich has been hammocking on

dev.4openID17:06:29

I am assuming it will be spec.alpha2 right?

Alex Miller (Clojure team)18:06:05

I’m hoping it will just be clojure.spec

seancorfield18:06:45

@dev.4openid I'm not Alex but my understanding is that Spec 2 will eventually become just clojure.spec when it is ready to come out of alpha -- and there's no timeframe for it yet, based on what I've seen/heard, since a lot of things are still being designed/revised.

seancorfield18:06:01

For a while, I kept a branch of our codebase current against that repo but it involved quite a few changes (and it had to keep changing as Spec 2 changed). I stopped tracking it back in ... September/October I think? Our approach going forward -- once Spec comes out of alpha -- will be to use the new Spec for new code we write and slowly, over time, migrate our Spec 1 code to "Spec 2" as needed. Spec 1 will stay available as-is "forever" so folks can stay on the old version if they don't want to migrate.

plins21:06:12

how can I create a generator from an arbitrary function? here’s a silly example but It would be something like (s/def ::name (s/spec string? :gen (constantly "Margaret"))) not sure if possible but id like to combine it with a lib like https://github.com/paraseba/faker to generate test data