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)))

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

standard clojure.test is assertions i mean

check returns results that you need to assert on

@lvh yes bug, and yes on core.typed

@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

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 clojure.java.jdbc 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 (https://github.com/gfredericks/test.chuck#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

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

tuple is probably the best match for an entry

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

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