This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-22
Channels
- # admin-announcements (4)
- # bangalore-clj (1)
- # beginners (28)
- # boot (16)
- # clara (4)
- # cljs-dev (28)
- # cljsrn (63)
- # clojure (136)
- # clojure-berlin (7)
- # clojure-gamedev (1)
- # clojure-nl (4)
- # clojure-russia (47)
- # clojure-sg (8)
- # clojure-spec (39)
- # clojure-uk (132)
- # clojurescript (66)
- # clojurex (5)
- # clojutre (2)
- # code-reviews (14)
- # core-logic (1)
- # cursive (13)
- # datavis (1)
- # datomic (35)
- # dirac (1)
- # editors (1)
- # hoplon (46)
- # jobs (1)
- # lambdaisland (5)
- # lein-figwheel (1)
- # mount (10)
- # off-topic (3)
- # om (67)
- # onyx (54)
- # planck (7)
- # proton (15)
- # protorepl (1)
- # re-frame (174)
- # ring (4)
- # ring-swagger (3)
- # specter (14)
- # untangled (15)
any plans for a with
macro for instrument/unstrument? That seems like an obvious thing to want 🙂
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)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
@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