Right, and I don't think the "this is closed we shouldn't discuss it anymore" line is great when people are advocating for a piece of functionality. I understand Alex doesn't want endless threads bikeshedding basically arbitrary naming choices, but that's not the same as people making simple points of "I think X would be a good addition because of Y" with no back and forth.
Maybe enough people saying "yes that sounds like a good idea because Y" in this thread will convince someone else that they should create a lib that mirrors the old functionality, this is the general Clojure group and not clojure-dev after all. Sorry about the meta. On Tuesday, July 19, 2016 at 3:51:09 PM UTC+10, Sean Corfield wrote: > > 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 > down a couple of other threads that have continued on past a clear line of > decision) > > > > I was sad to see :ret checking go away but I accept Rich’s line of > thinking on this and I’ll adjust my workflow accordingly. I find Rich’s > point that instrumentation is now about ensuring functions are _*called*_ > correctly rather than trying to establish that they _*behave*_ correctly > 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 <javascript:> > *Sent: *Monday, July 18, 2016 8:50 PM > *To: *Clojure <javascript:> > *Subject: *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 > complexity, and I'd add that side-effects are another reason for that. We > also have "you can just use assert on the return value" which is true, but > seeing as I already have a database of expected return values that I've > defined then it seems natural to be able to use that database to gain some > extra testing value rather than define it again. > > > > I'm not trying to argue for inclusion, if clojure core doesn't want to > implement the feature then those who see value in it can trivially > implement it themselves, but I haven't read anything that's made me think > it wouldn't be useful. > > > On Tuesday, July 19, 2016 at 12:53:49 PM UTC+10, Sean Corfield wrote: > > 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 not annoying somebody, you're not really alive." > -- Margaret Atwood > > > > On 7/18/16, 7:46 PM, "Oliver George" <clo...@googlegroups.com on behalf > of oli...@condense.com.au> wrote: > > > > 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. If it's > truly achievable the Clojure community could become known as an unstoppable > force of robust code. > > > > It would be something of a challenge for many of us... especially those > wanting this particular feature! > > > > > > On 19 July 2016 at 10:36, Beau Fabry <imf...@gmail.com> wrote: > > > 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 basically for free. Being able to do it > seems pragmatic. I'm hoping it won't be too difficult to write an > `overinstrument-all` that gives me that when I want it. > > > On Tuesday, July 12, 2016 at 5:36:39 PM UTC+10, Maarten Truyens wrote: > > 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 should not be far-fetched.) > > -- > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clo...@googlegroups.com <javascript:> > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+u...@googlegroups.com <javascript:> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+u...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
