Clojurians Log v2

I'll point you at https://corfield.org/blog/2019/09/13/using-spec/ for most of how we decided to do things. But TL;DR: we consider fdef to be dev/test-only; s/valid? or s/conform for production code; s/explain-data and custom heuristics for reporting; some use of exoscale/coax to perform coercion derived from Specs (trying to get away from our original use of Spec for coercion in a few places).

There are many answers to all of these of course, but general takes: • Where do you put the specs? ◦ For domain, I prefer one or more namespaces dedicated to this (consider two layers - one for types, one for attributes) and included via :as-alias ◦ For functions, in a foo.specs namespace • How do you validate the domain constructs? Via pre-/postconditions, within the functions via s/valid?, with s/fdefs and instrumentation or with custom validators? ◦ s/valid? for data validation from public inputs ◦ s/fdef / instrumentation for tests of functions • How do you report spec failures? Just the error or with explain or expound? ◦ for internal stuff, probably s/explain ◦ for public stuff, consider expound or custom • Do you validate at dev-time only or also in production? ◦ for user-side inputs, production ◦ for catching your own programming errors, dev-time only • What libs/tools do you use other than plain spec? ◦ test.chuck

Thanks for your answers, I really want to have some input on this. When I'm generating code with Claude Sonnet 4, it tends to produce co-located specs with pre-/postcondition validation. Especially pre-/postcondition validation is problematic, IMHO, because you have no influence on the error messages. Often it's not easy to see the root cause, becaue it gives you only the failed spec but not the data.

If I'm a bit settled on the options, I will make a prompt to guide AI on this.

I forgot we use test.chuck so a +1 for that and, yeah, basically agree with all of Alex's points.

I think many things I said are already in the spec guide https://clojure.org/guides/spec btw

There's nothing about code organization in that guide tho'... The guide is solid information to get a basic understanding of Spec but doesn't speak much to "best practices" in production, IMO.

And with guides it is not always clear if they are up to date, or if best practice or tools have evolved.

Normally I start with a single namespace and I segment it with: ;;;; <construct1> ;;;; <construct2> Inside each section, I have the specs for the domain construct, a constructor that uses s/valid, a validator function, and wtv function I need to operate on it. If that grows too big I can start splitting up some sections into their own namespace.

Something like:

(ns my-app.domain)

;;;; User

(s/def :user/attribute1 ...)
(s/def :user/attribute2 ...)
...

(s/def :user/user (s/keys ...))
(s/def :user/unregistered-user (s/keys ...))
...

(defn make-user! [...]
  (let [user ...]
    (when-not (s/valid? :user/user user)
      (throw ...))
    user))

(defn valid-user? [...]
  (s/valid? :user/user user))

(defn make-unregistered-user [...]
  ...)

(defn valid-unregistered-user? [...]
  (s/valid? :user/unregistered-user user))