Re: Thoughts on clojure.spec

For others, like me, who are finding this old thread interesting reading, there's a newer library that nicely addresses a concern expressed here, "Do you find it frustrating that there's no way to turn on instrumentation of function outputs for manual testing?" I am really enjoying and getting

Re: Thoughts on clojure.spec

I would certainly welcome and use an `overinstrument` function if added to schpec (or another library). One reason spec is great because it provides "a la carte" validation: a can add an appropriate amount of validation to the parts of my code that would most benefit from it. In my experience

Re: Thoughts on clojure.spec

I was just very surprised to discover my :ret specs were not being checked via instrument. I've read the rationale above, but I'm not yet convinced. While of course I can (and will) use spec/assert from a post condition, I lose the nice selective instrumentation features. I'd also like to make

Re: Thoughts on clojure.spec

ly >> oddly compelling, now that I’ve had some time to think about it and play >> with it  >> >> >> >> Sean Corfield -- (904) 302-SEAN >> An Architect's View -- http://corfield.org >> >> >> >> *From: *Beau Fabry >> *Se

Re: Thoughts on clojure.spec

orrectly > oddly compelling, now that I’ve had some time to think about it and play > with it  > > > > Sean Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org > > > > *From: *Beau Fabry > *Sent: *Monday, July 18, 2016 8:50 PM >

RE: Thoughts on clojure.spec

Well, both Alex and Rich have said the change is deliberate and there are no plans to change that decision – and Rich talked about ways you can add return value testing manually based on specs (if you want, but he won’t help you) – so it seems like a “closed” topic to me? (and Alex has shut

Re: Thoughts on clojure.spec

I think that was an explanation of why it's not particularly valuable in unit tests, but not really an explanation of why it wouldn't be useful in lower environments or canary boxes in distributed deployments. This thread has also touched on how not everything is gen-testable because of

Re: Thoughts on clojure.spec

Rich has given a pretty good explanation of why this was removed elsewhere. And in this thread, a week ago, he explained again why gen-testing :ret and :fn specs was the better approach. Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're

Re: Thoughts on clojure.spec

Here's the commit removing that aspect of instrument-all. Not a big change. https://github.com/clojure/clojure/commit/30dd3d8554ff96f1acda7cbe31470d92df2f565a As an aside, I also love the idea of the Clojure community fostering a culture of gen testing each chunk of well defined functionality.

Re: Thoughts on clojure.spec

> Do you find it frustrating that there's no way to turn on instrumentation of function outputs for manual testing? Yes. I've mentioned this elsewhere but I think being able to turn on output checking in lower environments (dev, test, master, staging) is getting extra values from specs

Re: Thoughts on clojure.spec

I would also truly appreciate instrumentation of function outputs for manual outputs. I understand the rationale for not having it as the default, but could it perhaps be specified as an option s/instrument? (Considering that it was present in the first alphas, I would assume that such option

Re: Thoughts on clojure.spec

Do you find it frustrating that there's no way to turn on instrumentation of function outputs for manual testing? Yes. On Mon, Jul 11, 2016 at 4:16 PM, Oliver George wrote: > > Do you find it frustrating that there's no way to turn on instrumentation >> of function

Re: Thoughts on clojure.spec

> Do you find it frustrating that there's no way to turn on instrumentation > of function outputs for manual testing? Yes. In particular when I'm refactoring code and want to know when I'm returning something surprising. I haven't yet had much success with spec generators for CLJS / UI

Re: Thoughts on clojure.spec

Kovas is right on the money here. Inherently when you make something ‘programmable’ generating correct programs for it is hard. I would say though, I frequently see people struggling to spec more complex logic are going directly to independent input generation. Thus, how will inputs be

Re: Thoughts on clojure.spec

On Sun, Jul 10, 2016 at 6:04 AM, Mark Engelberg wrote: > > This isn't due to anything inherent in clojure.spec, it's just that for > non-trivial functions, coming up with relevant random input is a very hard > problem. > This is a very interesting observation. I've

Re: Thoughts on clojure.spec

It might be possible to leverage something like American Fuzzy Lop[1] for better random input generation. I've never used AFL myself, but I know SQLite (one of the best-tested libraries I know of) has had good success with it[2], and it does work on Java. [1] http://lcamtuf.coredump.cx/afl/

Thoughts on clojure.spec

I've played around now with implementing specs for a couple of my projects. What I'm finding is that writing specs to check the inputs of a function is easy-ish, but building useful random generators is very hard -- in my projects, this seems too hard to do with any reasonable amount of effort.