This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-15
Channels
- # admin-announcements (7)
- # alda (1)
- # aws-lambda (1)
- # beginners (12)
- # boot (20)
- # cider (59)
- # cljs-dev (4)
- # cljsrn (69)
- # clojure (232)
- # clojure-austin (3)
- # clojure-austria (1)
- # clojure-belgium (2)
- # clojure-canada (3)
- # clojure-dev (16)
- # clojure-greece (33)
- # clojure-nl (4)
- # clojure-quebec (12)
- # clojure-russia (12)
- # clojure-spec (27)
- # clojure-uk (38)
- # clojurescript (29)
- # community-development (7)
- # component (53)
- # core-async (16)
- # core-logic (1)
- # datascript (7)
- # datomic (11)
- # editors (7)
- # emacs (69)
- # hoplon (157)
- # keechma (1)
- # lambdaisland (2)
- # lein-figwheel (31)
- # leiningen (8)
- # mount (3)
- # off-topic (11)
- # om (23)
- # onyx (64)
- # planck (2)
- # re-frame (18)
- # reagent (21)
- # specter (118)
- # untangled (145)
- # yada (1)
hi guys, how do we use variable inside s/keys
like this
(def a [::first-name])
(s/def ::user (s/keys :req a))
@nxqd: I don't think we can because s/keys
is a macro. Though I'm not sure if this is worth it for keys, as it doesn't capture predicates, I would expect it to be a function. As far as I can tell the only thing macro'ey it does is look at forms like (or ::foo ::bar)
.
At the moment you can't do this except via eval or something
But there has been talk of adding a fn entry point that would allow it
With check-fn
and check-var
, is there a way to get a "nice" explanation of the failures, like explain
produces?
I'm trying to see how the changes in Alpha 6 affect the testing workflow.
@nxqd: (somewhat belatedly) you can replace the var with the function that populates it (it can cache its results, if it's an expensive call), if it's a var that it makes sense to populate at macro eval time.
Unrelated: test.check has a fn (`fmap`) that lets you call an arbitrary fn on the results of a generator. But is there any way to create a generator that just calls an arbitrary fn? I haven't found one.
The only solution I've found so far is to do (fmap (fn [_] do-what-I-want) some-arbitrary-gen)
, but it's pretty ugly to put in a generator and then ignore what it generates.
Folks, is it a good idea to define fdef
function/macro specs next to the actual function/macro definition or would you rather define them in separate my-project.specs
kind of namespace?
I'd like to associate most of my functions with specs for automatted random function testing but at the same time I don't want to clutter my code base with specs too much.
Currently defining them on their own because it's still fairly experimental for us...but as we fully integrate them, I'll definitely consider moving them to live next to what they're speccing.
I think we’ll have data specs in separate namespaces. Not sure yet about function specs. Part of me would like them above function definitions — that seemed natural for when we used Schema and core.typed.
We went back and forth between core.typed and Schema several times before we abandoned them. With spec being in core, I think we’re more likely to stick with it.
Yeah. It also means you don't have to require the function namespaces and the function spec namespaces when you want to test functions.
Although, https://github.com/clojure/java.jdbc/blob/master/src/test/clojure/clojure/java/test_jdbc.clj#L28-L32
https://github.com/clojure/java.jdbc/blob/master/src/main/clojure/clojure/java/jdbc/spec.clj
There the function specs are in a separate clojure.java.jdbc.spec
namespace, below the data specs.
But that was mostly to ensure pre-1.9 code can still use the library
Here's my first attempt at writing function specs alongside the actual functions: https://github.com/workfloapp/macros/blob/jannis/clojure-spec/src/main/workflo/macros/props.cljc#L9
It would feel a little more natural to define the function spec like`:pre` and :post
, e.g.`(defn my-fun [arg1 arg2] {:spec {:args ... :ret ... :fn ...}} <body>)` or something like it, although there are good reasons to keep them separate.
@jannis: What do you think about putting the fdefs before the function? IMHO, that's a little clearer. I like having the function specs near the functions since that provides documentation when reading the function. Not sure about data specs, though.
what have I messed up here...?
Clojure 1.9.0-alpha7
Java HotSpot(TM) 64-Bit Server VM 1.8.0_65-b17
Exit: Control+D or (exit) or (quit)
Commands: (user/help)
Docs: (doc function-name-here)
(find-doc "part-of-name-here")
Find by Name: (find-name "part-of-name-here")
Source: (source function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Examples from : [clojuredocs or cdoc]
(user/clojuredocs name-here)
(user/clojuredocs "ns-here" "name-here")
boot.user=> (require '[clojure.spec :as s])
nil
boot.user=> (require '[clojure.spec.test :as t])
nil
boot.user=> (defn foo [x] (inc x))
#'boot.user/foo
boot.user=> (s/fdef foo :args (s/cat :x integer?) :ret integer?)
boot.user/foo
boot.user=> (t/check-var foo)
java.lang.IllegalArgumentException: No :args spec for boot.user$foo@5c60b94