Fork me on GitHub

atroche: nope but that sounds like a good idea 🙂


any plans for a with macro for instrument/unstrument? That seems like an obvious thing to want 🙂


I’m also wondering how to use check in a test suite


something like:

(deftest ^:generative check
  (stest/check (stest/enumerate-namespace 'obrysec.keychain)))
doesn’t do anything useful (doesn’t fail when it’s supposed to)


does check have a return value you can make assertions on?


standard clojure.test is assertions i mean

Alex Miller (Clojure team)03:08:42

check returns results that you need to assert on

Alex Miller (Clojure team)03:08:24

@lvh yes bug, and yes on core.typed

Alex Miller (Clojure team)03:08:56

@lvh the with instrument is interesting


Maybe I just haven’t seen the other use cases; it just seems obvious that I’d use it in a deftest

Alex Miller (Clojure team)03:08:31

You mean on instrument ? It's useful just to turn on instrumented specs at the repl


Hm, OK, that makes sense


I filed that issue, I’ll file another under… core.typed I guess


Done 🙂


@lvh Have you seen how deals with instrument in the test namespace?


For stest/check, you could look at stest/summarize-results which prints a nice summary of the success/failure and produces a hash map you can easily assert about (using is, for example).


We use Expectations, and with test.check we (expect (more-of {:keys [...]} ...) (property-based checks go here))


(or you can (map stest/abbrev-result (stest/check 'my-ns/foo)) and make assertions on each of those results)


I'm having a bit of pain with namespaced keywords - I have code that defines specs as namespaced keywords and expects to see those keywords used in calls to its functions - but it's super easy for a client to accidentally typo a new keyword into my namespace instead of referring to one that I've defined, and I can't catch the mistake if the keyword I've defined is optional


so I defined a map key as ::s3/bucket-name, and in the client code mistyped ::s3/ucket-name - it seems like a really obvious dumb error but I'm not sure I can do anything to catch it without starting to custom-code validation?


is there anything I can do in clojure to prevent keywords being defined into my namespace from outside (i.e. making that an error) or in spec to say that only the keys I've defined are valid - or have I misused something?


For the latter, (s/and (s/keys …) (s/map-of #{allowed-keys} any?)) is a possibility


@atroche I've always wanted a macro like this. Preferably allowing for with-test as well.


@donaldball nice, hadn't thought of that - only problem being the need to duplicate union of :req and :opt into it to achieve the effect... but helpful, thanks!


Could probably wrap it up in a nice macro


yeah - it doesn't seem like it would be a terrible idea to just have a flag or something on s/keys that made any keys that aren't in the union file


I get the argument for the leniency about composing functions to build up maps from the rationale, but it seems like there's a case for the final step in such a process where I need to assert that I've produced a valid result.


@lvh @seancorfield Re: unit/generative tests, with my existing test.check tests, I've had luck using something like times ( to run a small percentage of generative tests in my normal, fast feedback loop and then run the full amount less often.


I haven't yet tried that approach with the clojure.test generative testing, but it's been a useful technique so far


im trying to come up with a way to define a spec for a map, and also a spec for key/value pairs in that map


it also seems like something like this doesn’t work, which makes me think I’m headed in the wrong direction


You could define an entry as

(s/or :a ::a :b ::b :c ::c)


That would get you the values only, you might have to do something with tuples.


(s/tuple #{::a} int?)


Might start to get a little redundant

Alex Miller (Clojure team)21:08:44

Entries are collections and maps can be treated as collections of entries

Alex Miller (Clojure team)21:08:56

tuple is probably the best match for an entry

Alex Miller (Clojure team)21:08:01

So you can spec a map as a coll-of an or of tuples

Alex Miller (Clojure team)21:08:44

If you do so, you should also merge it with s/keys to get validation of values