Fork me on GitHub

Are there any common practices on how detailed people like to make their specs, in terms of trying to specify precisely which :args should be allowed, vs. which should not? In particular, I've been looking at clojure.set/rename-keys and how some values of the second argument lead to hard-to-predict return values.


Examples: (set/rename-keys {:a 1 😛 2 :c 3} {:a 😛 :c :b}) => {:b 3}


but: (set/rename-keys {:a 1 😛 2 :c 3} {:c 😛 :a :b}) => {:b 1}


If you see happy faces, those should be keywords with "b"


I could write a spec simply saying that the second parameter is a map?, but that would allow maps like the above to be included, which have unpredictable behavior.


I could also write a more restrictive spec for the 2nd arg that prevents any 2 values in the 2nd argument map from being equal to each other, which would avoid the unpredictable behavior.


For that same function, it is also clear that for generating random inputs that are "interesting", i.e. that don't simply always return their first argument with no changes, the keys in the first and second maps should often contain common values. So a useful generator that tries to exercise bugs in the implementation needs to steer inputs in that direction with high probability.


Anyway, looking for thoughts and recommendations there.


@andy.fingerhut I think a great deal comes down to how much effort you want to put into it. As sone as you start using very specific specs, you will also need to supply generators for those. While if you just want to have some edge cases tested, it would probably be less work to write specific tests for those. Depending on how you use specs, making them complex might also slow things down.


you can use ` to make it ignore emoji’s @andy.fingerhut


do one ` then another after you have finished


it should look like {:a 2 :b 3}


I’ve just released Expound 0.4.0. Now Expound will describe missing key specs