Fork me on GitHub
#clojure-spec
<
2018-10-03
>
fabrao13:10:15

Hello all, can I ask newbe question here? 🙂 I´m trying to figure out how to use spec in my projects.

fabrao13:10:26

Is that in repl development process?

fabrao13:10:22

Like I saw in this article https://blog.taylorwood.io/2017/10/15/fspec.html , so defn -> s/fdef -> stest/instrument -> stest/check ?

fabrao13:10:18

use as replacement of unit test?

taylor14:10:56

IMO they should supplement/augment tests, but not totally replace them

fabrao13:10:25

how do you use in your workflow daily?

taylor13:10:55

hey @fabrao, an example of how you might use it: have some defns you want to spec, write some specs/`fdef`s for those, then in a test namespace you might use check as part of a test

taylor13:10:28

and the specs/`fdef`s can be in the same file as the functions or separate, up to you

fabrao13:10:58

@taylor by the way, was you that wrote the artice?

taylor13:10:03

yes, thanks for reading 🙂

fabrao14:10:07

It was very clear about the propose of spec

👍 4
fabrao14:10:28

But you use it in your testing workflow?

taylor14:10:48

yes, I tend to use instrument more than check

fabrao14:10:58

but, have you already keep it on in production scenario?

fabrao14:10:29

for example to validade an csv file?

taylor14:10:44

no, instrument has a performance penalty, and anywhere I need to use spec "all the time" then I use the explicit conform/`valid?` kind of functions

taylor14:10:03

s/explain-data etc.

fabrao14:10:57

how do you use it in Exception scenarios?

taylor14:10:33

like if I wanted to throw an exception because of invalid input? Probably use ex-info and maybe put some of the s/explain-data into the info map

taylor14:10:50

you should also look into the expound library for spec

taylor14:10:31

that can help beautify spec's description of invalid inputs

fabrao14:10:12

I got it, but you mix real code with spec codes?

taylor14:10:57

in some cases yeah I might call s/conform or s/explain-data or s/assert from my "normal" code

taylor14:10:13

for always-on types of checks (asserts aside)

fabrao14:10:47

in case of using valid?, you use it inside your functions?

taylor14:10:24

probably not as often as the others, because I'm usually also interested in how/why the input was invalid

fabrao14:10:25

Yes, I don´t want to polute my code with spec[ing] stuffs

fabrao14:10:48

I want to be non intrusive checking

taylor14:10:09

yeah, overall I don't have many places in my projects where I'm explicitly interacting with spec in my app code/logic

fabrao14:10:59

yes, thank you about your help, I was afraid beeing specing everthing 🙂

taylor14:10:26

no problem, one great thing about spec is you can use it as little as you like 🙂

fabrao14:10:15

Yes, I saw many videos about it, but only shows something using valid? and nothing about the use like in your article

fabrao14:10:04

in this way, it´s better using typed-clojure than that 🙂

taylor14:10:25

I think that's fine (and it's cool that it's even possible) if that's your workflow, although personally I would probably just use regular defn and fdefs

taylor14:10:02

it's really up to how you want to use spec and structure your code :man-shrugging: try some different approaches and see what you like

fabrao14:10:54

Yes, I understood, thanks for your time. I´d appreciate all the subjects of your blog, all subject that I sometimes worked with

fabrao14:10:00

I´m using Instaparse in production already

fabrao14:10:38

that you can build your own language

taylor14:10:00

I've used Instaparse in a production project too, it's great

taylor13:10:26

you might choose to enable instrumentation for particular tests by calling instrument, or maybe in a dev profile so everything is instrumented at dev time

seancorfield17:10:30

@fabrao The other thing to bear in mind with spec is that there are two related but separate types of spec: data specs and function specs. At work, we rely heavily on the former in production code, where we call s/conform (mostly) and s/valid? on those specs and some data. We use function specs to support testing, either with st/instrument while we're developing or as part of a "unit test", or with st/check mostly while we're developing but also in small, limited tests (generative testing can take a while so it's not really designed as part of your short, fast "unit test" cycle).

👍 8
seancorfield17:10:21

We've been using spec in production pretty much since the first alpha dropped, back in the early 1.9 days. We love it!

taylor17:10:32

there's a Clojure 1.8 backport of clojure.spec I've used in production haha

seancorfield17:10:05

That appeared long after we were already on 1.9 and using spec in production tho' 🙂

👍 4
seancorfield17:10:18

We're currently on 1.10 Alpha 8 in production.

👏 4
fabrao17:10:56

@seancorfield I saw that we can use s/conform to contruct maps from data in more easy way

fabrao17:10:08

in that video explain lots of stuffs

seancorfield17:10:25

@fabrao Be careful about coercions and conformers in spec tho' -- consider those "very advanced" usage until you're comfortable with the rest of it in your workflow.

👍 4
seancorfield17:10:20

If you bake a coercion into your spec, you are "forcing" that coercion on all clients of the spec -- and it may have consequences for generators / generative testing.

seancorfield17:10:34

But, yeah, overall spec is awesome!

Scot22:10:29

Where's my error? What am I doing wrong?

Scot22:10:33

I'm sure I am doing something stupid, but I can't find any answers

noisesmith22:10:59

to verify an fdef I think you need to use instrument to explicitly turn on verification

noisesmith22:10:39

also beware of instrumenting functions that take function arguments - the spec is checked by passing various generated data to the function that was passed in

Scot22:10:18

So the only way to get runtime verification is via asserts?

noisesmith22:10:45

instrument turns on the validation of the function's spec, it's something you have to explicitly ask for

noisesmith22:10:43

if you want to ensure that a specific arg is always checked, you can use s/valid? as a predicate, or s/conform if you want an error for non-matching data