is anyone else struggling with a sudden ‘spec creep’ in their code ? how would one effectively determine what does and what does not belong in a spec ? e.g. if you’re accepting a file as a parameter, should you spec that this file exists, or should it only spec that it looks like a file ?

i’m err’ing towards making spec only define what things should look like

@lmergen I would assume that checking for file existence is not very useful since you need to check that actually opening the file succeeded anyway (and do something relevant when that failed). a file existing during precondition does not guarentee that it’s still there when you try to access it

that makes sense

depending on your code it may make sense to generate files though...

for checking

personally I’d try to avoid messing with the filesystem in tests and write as much as possible in terms of sequences or whatever makes sense to your problem

The idea with speccing function arguments as I understand it is to describe whatever input data that is supposed to be handled. In this case, handling non-existing files is sort of necessary given the mutable nature of the file system.

@lmergen My rule of thumb: spec predicates should be pure functions.

Another one: behaviour of the system should not change if spec checking is disabled (except for the boundaries where spec is explicitly used for parsing/destructuring external data). So all runtime error handling (file not found etc) ought to be in the function itself, and spec should only prevent programming errors.

what about s/conform ?

if you’re using that explicitly in your function body then you’ve sort of guaranteed the specs can’t be disabled 🙂

same with macros

that’s the parsing case that @dottedmag is talking about I think

are there any libs wich already have specs? just wanted to see some good examples of using specs

There are some specs for clojure.core already. Mostly macros.

nice!

@lmergen I found myself asking this question recently, and reading the rationale/motivation for spec made things a little clearer. while I like @dottedmag ‘s “only pure functions” rule of thumb, the spec guide itself has a section called “Using spec for validation” that includes several runtime validation examples which are not at the edge of the system at all, but which are deeply integrated. That level of integration makes me a bit nervous, but it’s clear that spec is integrated enough that this is a valid enough use case, at least for some people.

I’m struggling with how much spec right now

I’m thinking of putting it only where developers use the system (http endpoints, components apis,…)

https://github.com/boundlessgeo/spatialconnect-server/tree/master/server/src/spacon/specs

I’ve seen the most benefit in my system from using the generators after specing. Its found more bugs in there than our devs have seen using the functions that are spec’ed.

Has anyone had to spec something that might be used by older versions of clojure?

What's a good way of providing spec that's only read for 1.9+?

seperate namespace for the specs