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 > <javascript:> on behalf of oli...@condense.com.au <javascript:>> 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 <javascript:>> > 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 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.
