This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-29
Channels
- # aleph (1)
- # announcements (10)
- # aws (1)
- # beginners (110)
- # calva (4)
- # cider (26)
- # clj-kondo (14)
- # cljdoc (24)
- # cljsrn (16)
- # clojure (76)
- # clojure-europe (3)
- # clojure-ireland (2)
- # clojure-italy (15)
- # clojure-nl (8)
- # clojure-spec (23)
- # clojure-sweden (4)
- # clojure-uk (92)
- # clojurescript (37)
- # cursive (19)
- # datomic (59)
- # duct (1)
- # emacs (4)
- # fulcro (7)
- # graalvm (7)
- # graphql (1)
- # hoplon (69)
- # jobs (4)
- # jobs-rus (1)
- # kaocha (2)
- # leiningen (5)
- # luminus (2)
- # pathom (8)
- # reagent (6)
- # reitit (11)
- # spacemacs (12)
- # sql (3)
- # tools-deps (9)
- # unrepl (1)
- # vim (57)
I’m interested in using spec (for the first time) for a side project I’m working on. Where should I put the spec definitions? (Or is that a controversial question?)
I found this https://stackoverflow.com/questions/37942495/where-to-put-specs-for-clojure-spec But I’m not sure they came to a consensus in any of the answers/comments. (Or maybe I’m not sure how to interpret it because I’m still pretty new to spec)
@chrisreyes Most people tend to put data specs in their own namespace, possibly with a few utilities for processing that data, but put function specs next to (above) the functions to which they apply.
If you want specs to be "optional" for some functions, it makes sense to put them in a separate namespace, so that users can decide whether to load them or not.
Okay, thanks!
There is no "right way" or "wrong way" -- whatever is most convenient/makes the most sense.
When I added function specs to next.jdbc
recently, I put them all in a separate namespace, so users could choose whether to use them or not https://github.com/seancorfield/next-jdbc/blob/master/src/next/jdbc/specs.clj
That ns actually contains fdef
s for two other namespaces within the next.jdbc
project, just because that was the most natural/convenient way to set things up.
But having fdef
s separate isn't as common as having s/def
s for data separate.
Part of the issue is that specs can serve a lot of different purposes. They can be used for testing in several ways. They can be used to support development (`st/instrument` for example). They can be used in production for data validation (and other things).
What's & rest
in spec. I want to spec [:a :B :C :D] and make sure that first is :a and the rest can by of any amount of any type? (s/cat :need-a ::need-a (&rest?))
the nested s/*
(and other regex ops) is flattened out by default so that doesn't mean [:a [:b ...]]
ahh I see 🙂 thanks dj! Still after 2 years of spec, these basics are still troubling me
I guess with a lisp hat on you would expect it to nest, but if you were trying to imagine expressing regex via s-expressions it would look like that too so 🤷
Do people do generative testing over side-effectful code and/or integration tests?
I feel it is nice to be able to put an fdef
spec over an API endpoint on a webserver (e.g. required params and possible responses) but am unconvinced setting up the check as it starts becoming a bit like a super verbose example test. I suppose instrument with :stub
option could work but I'm trying to find a nice way of tying fdefs
into integration tests...
Speaking about integration / system tests, these talks https://lispcast.com/testing-stateful-and-concurrent-systems-using-test-check/, https://youtu.be/zjbcayvTcKQ and Datomic Simulat could be of interest. Regarding side-effects, I guess it depends on their kind. Some you certainly want to avoid when testing. (x with datmoic, you can use an "in-memory" local copy of the DB and never "commit" / transact into the original DB yet have everything there for verification.