Fork me on GitHub

@sophiago carin meier wrote a blog post about using spec to generate code that you might find interesting


also, i would like chime in that i also think it would be very interesting to read about generator combinators and category theory


I have a spec that I've written with clojure.spec and I can use it to generate valid Clojure data structures. Can I use it to generate invalid structures?


generating things in a negative way is hard to do in general


I expect clojure.spec makes no attempt to support that, since it's not obvious what strategy it would use


you can use unit testing for that, or custom generators to cover more specific cases


for a lot of cases you might do fine by using gen/any and filtering out things that match the spec


I did not know about gen/any, but that should do the trick. I was considering just creating a version of my schema where all required keys are instead marked as optional while also changing the data type / generators for some of the keys, but gen/any is simpler


are you guys converting database records field names to namespaced keywords?


or just specing database stuff with :req-un


I think converting would be cooler, but it takes more work and I haven't worked on something like that yet anyhow


e.g., a namespace per table


yes this is what i’d like


i spent some time specing all my stuff like that and while i can just use req-un i would rather see it qualified


would be great if i didn’t have to rename joined tables either, ie multiple id fields


there’s anyway to conform a spec given keys with :req-un into the matched qualified keywords?


I do not think so; do you have a particular use case for this?


FWIW supports producing qualified names via the :qualifier option. Doesn't handle joins tho'.


You could use s/describe on the spec to get the vector of :req-uns, and then pull the key with the name of the key you want to qualify, grab its namespace, and assoc a “newly created” fully qualified key onto the conformed data


If you really wanted to. 🙂


@seancorfield ya saw that, will probably do that for non joined data and use an identifier that will handle select AS statements


just as an exercise @naomarik :

(defn qualify-keys
  [spec conformed]
  (let [unq-to-qual (as-> (s/describe spec) $
                          (second (drop-while (partial not= :req-un) $))
                          (zipmap (map name $) $)
                          (reduce-kv #(assoc %1 (keyword %2) %3) {} $))]
    (reduce-kv #(assoc (dissoc %1 %2) %3 (get %1 %2))
               conformed unq-to-qual)))

(s/def string?)
(s/def :ns.two/reqkey string?)
(s/def ::mymap (s/keys :req-un [] :req [:ns.two/reqkey]))

(s/conform ::mymap {:ns.two/reqkey "required!" :requnkey "not required!"})
=> {:ns.two/reqkey "required!", :requnkey "not required!"}
(qualify-keys ::mymap *1)
=> {:ns.two/reqkey "required!", "not required!"}


@seancorfield you just mentioned in the #clojure channel about using with-redefs to stub functions for testing; what’s your take on taking a spec’d function and now being able to do this, versus the with-redefs approach?:

(stest/instrument `my-func {:stub #{`my-func}})


@joshjones I haven’t experimented with stubs in clojure.spec yet so I don’t have an opinion.


Mostly we’re spec’ing data structures and using s/conform etc — we’re not spec’ing functions much.


ok — I have not tried it for production-level testing either, but it looks useful:

(defn get-data-from-db [] nil)

(s/fdef get-data-from-db
        :args empty?
        :ret (s/int-in 1 10))

(stest/instrument `get-data-from-db {:stub #{`get-data-from-db}})

=> 6
=> 7


So it stubs the named function to return generated data per spec rather than actually calling it? Interesting. Wouldn’t work for anything that actually required mock state, rather than just stubbed data, but I can see that being useful sometimes.


I haven’t generally found stubs to be as useful as mocks so I don’t know how much I’d use it.


right, that’s a good point


I can see it being useful as you’re developing top-down where you stub functions as placeholders until you actually write them.


Right now, I’d actually write the physical stub… with the spec approach you could just get instrument to “write the stub” for you, but then you’d have to re-instrument or un-instrument as you actually wrote each function.


is there something you typically use for mocking state? or it just depends on your particular application?


How can i check in a spec for a key in a nested map ? so this is valid (s/explain ::objectNumber-list [{:body{:artObjects{:objectNumber "sk-c-5"}}}])


Since mocks tend to be pretty tied to your implementation, I generally just hand-roll them.


@roelof Please keep working in the #beginners channel on that.


You need to think carefully about the elements of that list, is all I’ll say.


@joshjones When we mock things, we tend to need to coordinate data across a series of calls — or even just record data across a series of calls — so custom functions that use atoms or refs to track that is our “go to” approach.


For example, we mock a payment provider to track calls and amounts, and pass or fail the transaction based on state.


I guess the amount of data you mock is pretty small though right? i.e., the purpose of the mocking at this stage is not for load-testing, which is done in a completely different way.


for example, we load test our elasticsearch code using dedicated aws servers, so it’s purely a load test — for testing correctness, etc., small amounts of mock data is used locally to be sure everything works as expected.


Mocking is to verify that a function calls some other function(s) in a particular way and/or that a series of calls to the mocked functions returns data in a particular way.


@roelof, you spec each value which is associated with a specific key and then specify which keys should be included in each map. Start with the innermost map(s) and work your way out.