This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-01-12
Channels
- # announcements (1)
- # babashka (32)
- # beginners (27)
- # calva (4)
- # clojure (18)
- # clojure-australia (2)
- # clojure-europe (11)
- # clojure-spec (8)
- # clojure-uk (15)
- # clojurescript (8)
- # cursive (14)
- # datomic (12)
- # fulcro (36)
- # graalvm (3)
- # graphql (2)
- # jobs (1)
- # meander (1)
- # pathom (5)
- # pedestal (12)
- # re-frame (1)
- # reagent (1)
- # reitit (2)
- # testing (12)
- # vim (2)
is there any guidance on where to start adding specs to an existing project?
my current strategy is basically to add specs to new code like I do tests. my next step will probably be trying to add specs as I happen to touch other code. however, I'm wondering about more proactive approaches.
@actuallyalys_slack I tend to focus on only adding specs where I think it will help me understand the code -- to avoid the temptation to treat Spec like a type system.
Common guidance is: write specs for your data structures but don't over-specify them; write specs for functions at "boundaries" (APIs of modules, for example) but don't get carried away. If you over-specify the code, it will be harder to make changes in the future because you may bake in assumptions that don't really hold as invariants over time.
good point. i'm not as worried about over-specification because instrumentation can always be turned off or specs commented out.
but there's still a time and mental cost to over-specified specs even so, so that's a good reminder.
i do think non-boundary specs can be useful because sometimes it's hard to know the exact shape of the data an internal function deals with or tedious to create it for the purpose of REPL experimentation. i guess that falls under "where i think it will help me understand the code"
Yup, I recently had to tackle a large part of our code base at work that I hadn't had to work on before and the first thing I did was to spec out some of the data structures, add some function specs, instrument the code and see what broke (and what worked) -- and then evolve the specs until everything worked again and that gave me a good understanding of what the data structures looked like and how the functions transformed them.