Q: Is there a reason why some clojure.test.check generators are excluded from clojure.spec.gen lazy primitives?
Is there a reason why some clojure.test.check generators are excluded from clojure.spec.gen lazy primitives? https://github.com/clojure/clojure/blob/1f25347a7b219488d5d9f8d17b04f2cc7828b30e/src/clj/clojure/spec/gen.clj#L114 The nat generator as one example is missing. Best regards, Joe N -- 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.
Re: clojure.test.check with fixtures
Hi, thank you, I just wanted to make sure I am not missing some functionality. Best Regards, Sven Am Mittwoch, 5. November 2014 23:29:54 UTC+1 schrieb Ashton Kemerling: You can use fixtures from Clojure.test, but each spec from the perspective of clojure.test includes multiple runs. So I use fixtures :once to do any global setup, and then farm out to a setup function for anything that needs to be done before each test run. --Ashton Sent from my iPhone On Nov 5, 2014, at 3:27 PM, Sven Richter sve...@googlemail.com javascript: wrote: Hi, Is there a way to use clojure.test.check's defspec with fixtures? Like (use-fixtures :each (partial wrap-setup setup teardown)) in clojures test library? How do other people execute setup and teardowns with clojure.test.check? Best Regards, Sven -- 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.
clojure.test.check with fixtures
Hi, Is there a way to use clojure.test.check's defspec with fixtures? Like (use-fixtures :each (partial wrap-setup setup teardown)) in clojures test library? How do other people execute setup and teardowns with clojure.test.check? Best Regards, Sven -- 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.
Re: clojure.test.check with fixtures
You can use fixtures from Clojure.test, but each spec from the perspective of clojure.test includes multiple runs. So I use fixtures :once to do any global setup, and then farm out to a setup function for anything that needs to be done before each test run. --Ashton Sent from my iPhone On Nov 5, 2014, at 3:27 PM, Sven Richter sver...@googlemail.com wrote: Hi, Is there a way to use clojure.test.check's defspec with fixtures? Like (use-fixtures :each (partial wrap-setup setup teardown)) in clojures test library? How do other people execute setup and teardowns with clojure.test.check? Best Regards, Sven -- 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. -- 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.
clojure.test.check
Hi
I have been trying to build a test.check generator for a multi map, without
much success.
I have a generator which generates ordinary maps:
(def ord-gen
(gen/fmap (partial zipmap [:port :instr :qty])
(gen/tuple (gen/not-empty gen/string-alpha-numeric)
(gen/not-empty gen/string-alpha-numeric)
(gen/frequency [[9 gen/pos-int] [1 gen/neg-int]]
(gen/sample ord-gen 3)
;; = ({:qty 0, :instr X4, :port re} {:qty 0, :instr v, :port 8}
{:qty 1, :instr 3A, :port 7})
However, I would like to merge this sequence of individual maps into a
multi-map of the form:
{re { X4 {:qty 0, :instr X4, :port re}}, 8 { v {:qty 0, :instr
v, :port 8}}, 7 { 3A {:qty 1, :instr 3A, :port 7}}}
The closest I have gotten to achieving this is by realising the
intermediate steps:
(def gen-cache
(-
(gen/fmap (fn [o]
(let [{:keys [port instr] :as ord} o]
(assoc-in {} [port instr] ord)))
ord-gen)
(gen/sample)
(reduce (fn [r m] (merge-with merge r m)) {})
(gen/return)))
However, this returns the same value constantly (I am aware that, that is
what gen/return is supposed to do, however, I can not get much else working
for me). I would Ideally like to bind the ord-gen into the gen-cache
generator. Any help would be very appreciated.
--
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.
Re: clojure.test.check
Hi,
I've taken a stab at what I think you want:
(def gen-cache
(gen/fmap
#(reduce (fn [r m] (merge-with merge r m)) {} %)
(gen/vector (gen/fmap
(fn [o]
(let [{:keys [port instr] :as ord} o]
(assoc-in {} [port instr] ord)))
ord-gen
Instead of using `gen/sample` to create a sequence, I use `gen/vector`. And in
order to apply the `reduce` function, I use `gen/fmap`.
As an aside, I'm not sure how this is a multi-map. I was under the impression a
multi-map was simply a map that can store multiple values in the same key.
Reid
On Thursday, July 3, 2014 6:06:29 AM UTC-5, cig wrote:
Hi
I have been trying to build a test.check generator for a multi map,
without much success.
I have a generator which generates ordinary maps:
(def ord-gen
(gen/fmap (partial zipmap [:port :instr :qty])
(gen/tuple (gen/not-empty gen/string-alpha-numeric)
(gen/not-empty gen/string-alpha-numeric)
(gen/frequency [[9 gen/pos-int] [1 gen/neg-int]]
(gen/sample ord-gen 3)
;; = ({:qty 0, :instr X4, :port re} {:qty 0, :instr v, :port 8}
{:qty 1, :instr 3A, :port 7})
However, I would like to merge this sequence of individual maps into a
multi-map of the form:
{re { X4 {:qty 0, :instr X4, :port re}}, 8 { v {:qty 0, :instr
v, :port 8}}, 7 { 3A {:qty 1, :instr 3A, :port 7}}}
The closest I have gotten to achieving this is by realising the
intermediate steps:
(def gen-cache
(-
(gen/fmap (fn [o]
(let [{:keys [port instr] :as ord} o]
(assoc-in {} [port instr] ord)))
ord-gen)
(gen/sample)
(reduce (fn [r m] (merge-with merge r m)) {})
(gen/return)))
However, this returns the same value constantly (I am aware that, that is
what gen/return is supposed to do, however, I can not get much else working
for me). I would Ideally like to bind the ord-gen into the gen-cache
generator. Any help would be very appreciated.
--
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.
Re: clojure.test.check
Hi Reid
Yes that's exactly what I was trying to achieve. Thank you very much.
As for the multi-maps. I was simply using the term incorrectly, sorry for
the confusion.
Thanks once again
On Thursday, 3 July 2014 16:44:29 UTC+2, Reid Draper wrote:
Hi,
I've taken a stab at what I think you want:
(def gen-cache
(gen/fmap
#(reduce (fn [r m] (merge-with merge r m)) {} %)
(gen/vector (gen/fmap
(fn [o]
(let [{:keys [port instr] :as ord} o]
(assoc-in {} [port instr] ord)))
ord-gen
Instead of using `gen/sample` to create a sequence, I use `gen/vector`. And
in order to apply the `reduce` function, I use `gen/fmap`.
As an aside, I'm not sure how this is a multi-map. I was under the impression
a multi-map was simply a map that can store multiple values in the same key.
Reid
On Thursday, July 3, 2014 6:06:29 AM UTC-5, cig wrote:
Hi
I have been trying to build a test.check generator for a multi map,
without much success.
I have a generator which generates ordinary maps:
(def ord-gen
(gen/fmap (partial zipmap [:port :instr :qty])
(gen/tuple (gen/not-empty gen/string-alpha-numeric)
(gen/not-empty gen/string-alpha-numeric)
(gen/frequency [[9 gen/pos-int] [1
gen/neg-int]]
(gen/sample ord-gen 3)
;; = ({:qty 0, :instr X4, :port re} {:qty 0, :instr v, :port 8}
{:qty 1, :instr 3A, :port 7})
However, I would like to merge this sequence of individual maps into a
multi-map of the form:
{re { X4 {:qty 0, :instr X4, :port re}}, 8 { v {:qty 0,
:instr v, :port 8}}, 7 { 3A {:qty 1, :instr 3A, :port 7}}}
The closest I have gotten to achieving this is by realising the
intermediate steps:
(def gen-cache
(-
(gen/fmap (fn [o]
(let [{:keys [port instr] :as ord} o]
(assoc-in {} [port instr] ord)))
ord-gen)
(gen/sample)
(reduce (fn [r m] (merge-with merge r m)) {})
(gen/return)))
However, this returns the same value constantly (I am aware that, that is
what gen/return is supposed to do, however, I can not get much else working
for me). I would Ideally like to bind the ord-gen into the gen-cache
generator. Any help would be very appreciated.
--
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.
Re: [ANN] clojure.test.check 0.5.8
On May 15, 2014, at 2:08 PM, Steve Miner stevemi...@gmail.com wrote: I'm generating generators from schemas [1]. I have generators for all my simple schemas -- int corresponds to gen/int, etc. The tougher case is when I have to convert a conjunction of schema expressions into a generator. For example, a schema (and int pos) specifies a positive integer, essentially like testing (fn [x] (and (integer? x) (pos? x)). My current implementation finds some element of the AND that I can map to a generator and uses such-that to filter against a predicate created from the rest of the AND elements. A simple example does something like this... (make-generator '(and int pos odd)) --- (gen/such-that (make-predicate '(and pos odd)) (make-generator 'int)) --- (gen/such-that (fn [x] (and (pos? x) (odd? x))) gen/int) Of course, it would be better to use gen/s-pos-int. I'm thinking that I need to look for a few common combinations of simple schemas, especially if there's already a good generator for those cases. However, I still need to try to handle the general case, and it looks like the such-that approach will have to be my fallback position. I'll probably give the user the option of adding custom generators to match more complicated schema expressions. Yes, I think you're thinking about this correctly. And in some cases, you may be better off just wasting some CPU cycles and using such-that, just like you are. It really depends on how complex you want your library to be. Now, if you could provide an efficient AND generator combinator, that would solve all my problems. :-) I'll give this some thought :) It occurs to me that automatically deriving generators is something like running a predicate backwards so maybe there's a way to do it with core.logic, but I haven't tried to do that yet. Let me know how this goes. Reid -- 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.
Re: [ANN] clojure.test.check 0.5.8
Sorry you ran into an issue, Steve. I like your idea of including more information in the ex-info data. Is there a specific generator you're having trouble writing without such-that? In general, I've found that it's a code-smell if you need such-that to retry that many times. Happy to help explore other ways to write these generators. Best, Reid On Wednesday, May 14, 2014 12:13:14 PM UTC-5, miner wrote: On May 14, 2014, at 10:44 AM, Reid Draper reidd...@gmail.comjavascript: wrote: * Limit the number of retries for gen/such-that. A two-arity version is provided if you need to retry more than 10 times. This should be a code-smell, though. I think the limit is a good idea, but it's an extra wrinkle and maybe too tight. I had a such-that that failed due to the new limit. Unfortunately, the error message didn't help much in tracking it down. I ended up changing all my such-that calls to use a unique number of retries so I could figure which one was failing. I suppose my situation is unusual in that I generate generators and tests from schemas and data. The stack traces aren't very pretty when there are errors. It might help if you added the 'pred' and 'tries' to the ex-info data in such-that-helper. Might as well put something in the ex-info data. By the way, it turns out 25 was a sufficient number of retries for my test. Works fine now. Steve Miner -- 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.
Re: [ANN] clojure.test.check 0.5.8
On May 15, 2014, at 1:03 PM, Reid Draper reiddra...@gmail.com wrote: Sorry you ran into an issue, Steve. I like your idea of including more information in the ex-info data. Is there a specific generator you're having trouble writing without such-that? In general, I've found that it's a code-smell if you need such-that to retry that many times. Happy to help explore other ways to write these generators. I'm generating generators from schemas [1]. I have generators for all my simple schemas -- int corresponds to gen/int, etc. The tougher case is when I have to convert a conjunction of schema expressions into a generator. For example, a schema (and int pos) specifies a positive integer, essentially like testing (fn [x] (and (integer? x) (pos? x)). My current implementation finds some element of the AND that I can map to a generator and uses such-that to filter against a predicate created from the rest of the AND elements. A simple example does something like this... (make-generator '(and int pos odd)) --- (gen/such-that (make-predicate '(and pos odd)) (make-generator 'int)) --- (gen/such-that (fn [x] (and (pos? x) (odd? x))) gen/int) Of course, it would be better to use gen/s-pos-int. I'm thinking that I need to look for a few common combinations of simple schemas, especially if there's already a good generator for those cases. However, I still need to try to handle the general case, and it looks like the such-that approach will have to be my fallback position. I'll probably give the user the option of adding custom generators to match more complicated schema expressions. Now, if you could provide an efficient AND generator combinator, that would solve all my problems. :-) It occurs to me that automatically deriving generators is something like running a predicate backwards so maybe there's a way to do it with core.logic, but I haven't tried to do that yet. I'd be happy to consider any suggestions. Thanks, Steve Miner [1] https://github.com/miner/herbert -- 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.
[ANN] clojure.test.check 0.5.8
I'm please to announce clojure.test.check 0.5.8 [1], which is primarily a bugfix release. As usual, the release notes are available in the repository [2]. I've duplicated them here for convenience: * 0.5.8 * Limit the number of retries for gen/such-that. A two-arity version is provided if you need to retry more than 10 times. This should be a code-smell, though. * Return random seed used on test failure * Fix keyword generator to conform to reader specs * Correct documentation mentions of namespaces * Add more detailed contributing instructions * Internal: use a record internally for generators. This is meant to help convey the fact that generators are opaque * Extract rose-tree code into a separate namespace Please don't hesitate to reach out with any questions or issues. Reid [1] https://github.com/clojure/test.check/tree/v0.5.8 [2] https://github.com/clojure/test.check/blob/v0.5.8/CHANGELOG.markdown -- 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.
Re: [ANN] clojure.test.check 0.5.8
On May 14, 2014, at 10:44 AM, Reid Draper reiddra...@gmail.com wrote: * Limit the number of retries for gen/such-that. A two-arity version is provided if you need to retry more than 10 times. This should be a code-smell, though. I think the limit is a good idea, but it's an extra wrinkle and maybe too tight. I had a such-that that failed due to the new limit. Unfortunately, the error message didn't help much in tracking it down. I ended up changing all my such-that calls to use a unique number of retries so I could figure which one was failing. I suppose my situation is unusual in that I generate generators and tests from schemas and data. The stack traces aren't very pretty when there are errors. It might help if you added the 'pred' and 'tries' to the ex-info data in such-that-helper. Might as well put something in the ex-info data. By the way, it turns out 25 was a sufficient number of retries for my test. Works fine now. Steve Miner -- 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.
Re: testing clojure.core/group-by with clojure.test.check
thanks Alex and others for helping out. Some very interesting ideas here but the one about leveraging the grouping function seemed easy and reading that was an epiphany moment where i realised i had been subconsciously constrained by thinking I should generate data and use a grouping fn that was similar to the narrow ways I happen to have used the group-by fn in the past. I would like to read more though and if I see good resources on scala or haskell equivalent I will try to pass on via pull request. fyi, here are encodings of the 3 properties I originally stated. I used count for group-by fn in all 3. ;;test group by (def vector-of-strings (gen/vector gen/string)) (def grouping-retains-all-input flattening the vals of the group-by result should give back contents of the original collection (prop/for-all [group-by-input vector-of-strings] (= (set group-by-input) (- (group-by count group-by-input) vals flatten set (def all-members-under-grouping-key-should-be-there applying the grouping fn to each item under a grouping should result in the grouping key (prop/for-all [group-by-input vector-of-strings] (every? #(= true %) (map (fn [[key group]] (apply = key (map count group))) (group-by count group-by-input) (def grouping-does-not-duplicate (prop/for-all [group-by-input vector-of-strings] (= (count group-by-input) (- (group-by count group-by-input) vals flatten count On Thursday, May 1, 2014 12:49:31 AM UTC+1, Andrew Chambers wrote: One approach you can use is write the generators in such a way that they generate the final answer group-by should return, then you write code which does the inverse to group by and then you check the group by answer is equal to the originally generated solution. On Wednesday, April 30, 2014 11:38:19 PM UTC+12, henry w wrote: Hi, I wanted to get started with clojure.test.check (formerly simple-check) and I am new to property based testing. I plucked clojure.core/group-by for no particular reason as a function to test. I started by stating some properties i think should hold: ;; 1. applying the grouping key function to each member in a grouping should result in the grouping key ;; 2. flattening the vals of the group-by result should give back the contents of the original collection. ;; 3. no element appears in more than one grouping. so far so good I think. there may be others but this seems ok for now. now, how to generate some data. for group-by we need two params: 1) a grouping function 2) a collection of items to be grouped If I start by naively generating collections of maps (containing keyword keys and int vals, for example), the data is of the right shape to use in group by, but there is no guarantee that: 1) any of the maps share a key that I could use for grouping 2) the values under a common key are shared This is really the crux of my problem ideally I would have the generator *mostly* produce data which is actually doing to result in the sort of collection i might want to call group-by on in real life (ie not have everything grouped under nil on each generation). So should i create a generator that creates keywords (which i will want to use as grouping function) then have another generator that produces what are going to be the values under this grouping key, then a generator that uses both of these to create collections of maps from these. then i would have to find out what the grouping keyword was that was generated this could all work, I have read enough about generators to have a stab at this... but is it the right approach? as far as implementing tests for the properties so far, I have done property 2 above, using a basic generator and yanking out an arbitrary key from it clearly a flawed approach as not much 'realistic' grouping is going to happen here. (def vector-of-maps (gen/such-that not-empty (gen/vector (gen/such-that not-empty (gen/map gen/keyword gen/int) (def all-elements-are-grouped (prop/for-all [group-by-input vector-of-maps] (let [a-map-key (- group-by-input first keys first)] ;; hmm, seems far from ideal (= (set group-by-input) (- (group-by a-map-key group-by-input) vals flatten set) help appreciated... perhaps I need to learn more about the paradigm first, but resources linked from the readme are all a bit more basic than this. so if you know of some more advanced tutorials please let me know. Thanks -- 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
testing clojure.core/group-by with clojure.test.check
Hi, I wanted to get started with clojure.test.check (formerly simple-check) and I am new to property based testing. I plucked clojure.core/group-by for no particular reason as a function to test. I started by stating some properties i think should hold: ;; 1. applying the grouping key function to each member in a grouping should result in the grouping key ;; 2. flattening the vals of the group-by result should give back the contents of the original collection. ;; 3. no element appears in more than one grouping. so far so good I think. there may be others but this seems ok for now. now, how to generate some data. for group-by we need two params: 1) a grouping function 2) a collection of items to be grouped If I start by naively generating collections of maps (containing keyword keys and int vals, for example), the data is of the right shape to use in group by, but there is no guarantee that: 1) any of the maps share a key that I could use for grouping 2) the values under a common key are shared This is really the crux of my problem ideally I would have the generator *mostly* produce data which is actually doing to result in the sort of collection i might want to call group-by on in real life (ie not have everything grouped under nil on each generation). So should i create a generator that creates keywords (which i will want to use as grouping function) then have another generator that produces what are going to be the values under this grouping key, then a generator that uses both of these to create collections of maps from these. then i would have to find out what the grouping keyword was that was generated this could all work, I have read enough about generators to have a stab at this... but is it the right approach? as far as implementing tests for the properties so far, I have done property 2 above, using a basic generator and yanking out an arbitrary key from it clearly a flawed approach as not much 'realistic' grouping is going to happen here. (def vector-of-maps (gen/such-that not-empty (gen/vector (gen/such-that not-empty (gen/map gen/keyword gen/int) (def all-elements-are-grouped (prop/for-all [group-by-input vector-of-maps] (let [a-map-key (- group-by-input first keys first)] ;; hmm, seems far from ideal (= (set group-by-input) (- (group-by a-map-key group-by-input) vals flatten set) help appreciated... perhaps I need to learn more about the paradigm first, but resources linked from the readme are all a bit more basic than this. so if you know of some more advanced tutorials please let me know. Thanks -- 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.
Re: testing clojure.core/group-by with clojure.test.check
The only hard parts about property based testing are the properties and the generators. ;) On Wednesday, April 30, 2014 6:38:19 AM UTC-5, henry w wrote: Hi, I wanted to get started with clojure.test.check (formerly simple-check) and I am new to property based testing. I plucked clojure.core/group-by for no particular reason as a function to test. I started by stating some properties i think should hold: ;; 1. applying the grouping key function to each member in a grouping should result in the grouping key ;; 2. flattening the vals of the group-by result should give back the contents of the original collection. ;; 3. no element appears in more than one grouping. those seem good so far so good I think. there may be others but this seems ok for now. now, how to generate some data. for group-by we need two params: 1) a grouping function 2) a collection of items to be grouped If I start by naively generating collections of maps (containing keyword keys and int vals, for example), the data is of the right shape to use in group by, but there is no guarantee that: 1) any of the maps share a key that I could use for grouping 2) the values under a common key are shared This is really the crux of my problem ideally I would have the generator *mostly* produce data which is actually doing to result in the sort of collection i might want to call group-by on in real life (ie not have everything grouped under nil on each generation). So should i create a generator that creates keywords (which i will want to use as grouping function) then have another generator that produces what are going to be the values under this grouping key, then a generator that uses both of these to create collections of maps from these. then i would have to find out what the grouping keyword was that was generated this could all work, I have read enough about generators to have a stab at this... but is it the right approach? You don't seem to be leveraging the possibilities of the grouping function. If you create a grouping function that maps many random values into a small number of groups, then everything may get easier. Some candidate functions: first character of the keyword, length of the keyword, etc. Or working backwards is often useful with a generator - generate the grouping values first, then use the inverse of the grouping function to generate data that maps to that group and populate the input with that. as far as implementing tests for the properties so far, I have done property 2 above, using a basic generator and yanking out an arbitrary key from it clearly a flawed approach as not much 'realistic' grouping is going to happen here. (def vector-of-maps (gen/such-that not-empty (gen/vector (gen/such-that not-empty (gen/map gen/keyword gen/int) (def all-elements-are-grouped (prop/for-all [group-by-input vector-of-maps] (let [a-map-key (- group-by-input first keys first)] ;; hmm, seems far from ideal (= (set group-by-input) (- (group-by a-map-key group-by-input) vals flatten set) help appreciated... perhaps I need to learn more about the paradigm first, but resources linked from the readme are all a bit more basic than this. so if you know of some more advanced tutorials please let me know. Thanks -- 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.
Re: testing clojure.core/group-by with clojure.test.check
As an aside to the discussion at hand, what papers/books/online articles are good to read to learn about how to come up with good properties and generators? On Wed, Apr 30, 2014 at 3:36 PM, Alex Miller a...@puredanger.com wrote: The only hard parts about property based testing are the properties and the generators. ;) On Wednesday, April 30, 2014 6:38:19 AM UTC-5, henry w wrote: Hi, I wanted to get started with clojure.test.check (formerly simple-check) and I am new to property based testing. I plucked clojure.core/group-by for no particular reason as a function to test. I started by stating some properties i think should hold: ;; 1. applying the grouping key function to each member in a grouping should result in the grouping key ;; 2. flattening the vals of the group-by result should give back the contents of the original collection. ;; 3. no element appears in more than one grouping. those seem good so far so good I think. there may be others but this seems ok for now. now, how to generate some data. for group-by we need two params: 1) a grouping function 2) a collection of items to be grouped If I start by naively generating collections of maps (containing keyword keys and int vals, for example), the data is of the right shape to use in group by, but there is no guarantee that: 1) any of the maps share a key that I could use for grouping 2) the values under a common key are shared This is really the crux of my problem ideally I would have the generator *mostly* produce data which is actually doing to result in the sort of collection i might want to call group-by on in real life (ie not have everything grouped under nil on each generation). So should i create a generator that creates keywords (which i will want to use as grouping function) then have another generator that produces what are going to be the values under this grouping key, then a generator that uses both of these to create collections of maps from these. then i would have to find out what the grouping keyword was that was generated this could all work, I have read enough about generators to have a stab at this... but is it the right approach? You don't seem to be leveraging the possibilities of the grouping function. If you create a grouping function that maps many random values into a small number of groups, then everything may get easier. Some candidate functions: first character of the keyword, length of the keyword, etc. Or working backwards is often useful with a generator - generate the grouping values first, then use the inverse of the grouping function to generate data that maps to that group and populate the input with that. as far as implementing tests for the properties so far, I have done property 2 above, using a basic generator and yanking out an arbitrary key from it clearly a flawed approach as not much 'realistic' grouping is going to happen here. (def vector-of-maps (gen/such-that not-empty (gen/vector (gen/such-that not-empty (gen/map gen/keyword gen/int) (def all-elements-are-grouped (prop/for-all [group-by-input vector-of-maps] (let [a-map-key (- group-by-input first keys first)] ;; hmm, seems far from ideal (= (set group-by-input) (- (group-by a-map-key group-by-input) vals flatten set) help appreciated... perhaps I need to learn more about the paradigm first, but resources linked from the readme are all a bit more basic than this. so if you know of some more advanced tutorials please let me know. Thanks -- 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. -- 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.
Re: testing clojure.core/group-by with clojure.test.check
Some good links here: https://github.com/clojure/test.check But related communities like QuickCheck, ScalaCheck, etc are probably good places to look. Someone should start making something great for test.check on the wiki: https://github.com/clojure/test.check Hint hint hint! On Wednesday, April 30, 2014 3:10:34 PM UTC-5, Tim Visher wrote: As an aside to the discussion at hand, what papers/books/online articles are good to read to learn about how to come up with good properties and generators? On Wed, Apr 30, 2014 at 3:36 PM, Alex Miller al...@puredanger.comjavascript: wrote: The only hard parts about property based testing are the properties and the generators. ;) On Wednesday, April 30, 2014 6:38:19 AM UTC-5, henry w wrote: Hi, I wanted to get started with clojure.test.check (formerly simple-check) and I am new to property based testing. I plucked clojure.core/group-by for no particular reason as a function to test. I started by stating some properties i think should hold: ;; 1. applying the grouping key function to each member in a grouping should result in the grouping key ;; 2. flattening the vals of the group-by result should give back the contents of the original collection. ;; 3. no element appears in more than one grouping. those seem good so far so good I think. there may be others but this seems ok for now. now, how to generate some data. for group-by we need two params: 1) a grouping function 2) a collection of items to be grouped If I start by naively generating collections of maps (containing keyword keys and int vals, for example), the data is of the right shape to use in group by, but there is no guarantee that: 1) any of the maps share a key that I could use for grouping 2) the values under a common key are shared This is really the crux of my problem ideally I would have the generator *mostly* produce data which is actually doing to result in the sort of collection i might want to call group-by on in real life (ie not have everything grouped under nil on each generation). So should i create a generator that creates keywords (which i will want to use as grouping function) then have another generator that produces what are going to be the values under this grouping key, then a generator that uses both of these to create collections of maps from these. then i would have to find out what the grouping keyword was that was generated this could all work, I have read enough about generators to have a stab at this... but is it the right approach? You don't seem to be leveraging the possibilities of the grouping function. If you create a grouping function that maps many random values into a small number of groups, then everything may get easier. Some candidate functions: first character of the keyword, length of the keyword, etc. Or working backwards is often useful with a generator - generate the grouping values first, then use the inverse of the grouping function to generate data that maps to that group and populate the input with that. as far as implementing tests for the properties so far, I have done property 2 above, using a basic generator and yanking out an arbitrary key from it clearly a flawed approach as not much 'realistic' grouping is going to happen here. (def vector-of-maps (gen/such-that not-empty (gen/vector (gen/such-that not-empty (gen/map gen/keyword gen/int) (def all-elements-are-grouped (prop/for-all [group-by-input vector-of-maps] (let [a-map-key (- group-by-input first keys first)] ;; hmm, seems far from ideal (= (set group-by-input) (- (group-by a-map-key group-by-input) vals flatten set) help appreciated... perhaps I need to learn more about the paradigm first, but resources linked from the readme are all a bit more basic than this. so if you know of some more advanced tutorials please let me know. Thanks -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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
Re: testing clojure.core/group-by with clojure.test.check
One approach you can use is write the generators in such a way that they generate the final answer group-by should return, then you write code which does the inverse to group by and then you check the group by answer is equal to the originally generated solution. On Wednesday, April 30, 2014 11:38:19 PM UTC+12, henry w wrote: Hi, I wanted to get started with clojure.test.check (formerly simple-check) and I am new to property based testing. I plucked clojure.core/group-by for no particular reason as a function to test. I started by stating some properties i think should hold: ;; 1. applying the grouping key function to each member in a grouping should result in the grouping key ;; 2. flattening the vals of the group-by result should give back the contents of the original collection. ;; 3. no element appears in more than one grouping. so far so good I think. there may be others but this seems ok for now. now, how to generate some data. for group-by we need two params: 1) a grouping function 2) a collection of items to be grouped If I start by naively generating collections of maps (containing keyword keys and int vals, for example), the data is of the right shape to use in group by, but there is no guarantee that: 1) any of the maps share a key that I could use for grouping 2) the values under a common key are shared This is really the crux of my problem ideally I would have the generator *mostly* produce data which is actually doing to result in the sort of collection i might want to call group-by on in real life (ie not have everything grouped under nil on each generation). So should i create a generator that creates keywords (which i will want to use as grouping function) then have another generator that produces what are going to be the values under this grouping key, then a generator that uses both of these to create collections of maps from these. then i would have to find out what the grouping keyword was that was generated this could all work, I have read enough about generators to have a stab at this... but is it the right approach? as far as implementing tests for the properties so far, I have done property 2 above, using a basic generator and yanking out an arbitrary key from it clearly a flawed approach as not much 'realistic' grouping is going to happen here. (def vector-of-maps (gen/such-that not-empty (gen/vector (gen/such-that not-empty (gen/map gen/keyword gen/int) (def all-elements-are-grouped (prop/for-all [group-by-input vector-of-maps] (let [a-map-key (- group-by-input first keys first)] ;; hmm, seems far from ideal (= (set group-by-input) (- (group-by a-map-key group-by-input) vals flatten set) help appreciated... perhaps I need to learn more about the paradigm first, but resources linked from the readme are all a bit more basic than this. so if you know of some more advanced tutorials please let me know. Thanks -- 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.
Re: [ANN] clojure.test.check (previously, simple-check)
Nooo :-(. Now it gets behind the CA + Jira impenetrable wall. El jueves, 27 de febrero de 2014 11:22:44 UTC-6, Reid Draper escribió: I'm happy to announce the first release of the newest Clojure contrib library: test.check [1]. Previously named simple-check [1], test.check is a property-based testing library, based on QuickCheck. The README has a guide for migrating from simple-check, as well as some getting-started documentation. I'm happy to answer any questions here as well. Or, stop by my Clojure/West talk in March. [1] https://github.com/clojure/test.check [2] https://github.com/reiddraper/simple-check -- 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/groups/opt_out.
Re: [ANN] clojure.test.check (previously, simple-check)
On Mar 1, 2014, at 11:30 AM, César Bolaños Portilla cesar.bolanosporti...@gmail.com wrote: Nooo :-(. Now it gets behind the CA + Jira impenetrable wall. Please let's not have this debate again. Hundreds of people clearly find it less than impenetrable and the process is _necessary_ from a legal point of view: http://clojure.org/contributing Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [ANN] clojure.test.check (previously, simple-check)
Reid, Thank you kindly. That makes sense. Your help is much appreciated, as are your efforts with this library. Thanks, Andrew On Thursday, 27 February 2014 17:22:44 UTC, Reid Draper wrote: I'm happy to announce the first release of the newest Clojure contrib library: test.check [1]. Previously named simple-check [1], test.check is a property-based testing library, based on QuickCheck. The README has a guide for migrating from simple-check, as well as some getting-started documentation. I'm happy to answer any questions here as well. Or, stop by my Clojure/West talk in March. [1] https://github.com/clojure/test.check [2] https://github.com/reiddraper/simple-check -- 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/groups/opt_out.
Re: [ANN] clojure.test.check (previously, simple-check)
Hi Reid, This is excellent. Just experimenting and trying to get my head around it. Not sure if I'm doing any wrong or stupid!! If I test a function that relies on Exception handling internally as I reach 100 tests it takes forever and eventually blows the heap. Simple contrived example: (ns check (:require [clojure.test.check :as tc] [clojure.test.check.generators :as gen] [clojure.test.check.properties :as prop] )) (defn format1 [x] (try (- (double x) (format %,.0f)) (catch Exception e ))) (def prop1 (prop/for-all [v gen/any] (string? (format1 v #_ (tc/quick-check 100 prop1) ;; blows heap Thanks, Andrew On Thursday, 27 February 2014 17:22:44 UTC, Reid Draper wrote: I'm happy to announce the first release of the newest Clojure contrib library: test.check [1]. Previously named simple-check [1], test.check is a property-based testing library, based on QuickCheck. The README has a guide for migrating from simple-check, as well as some getting-started documentation. I'm happy to answer any questions here as well. Or, stop by my Clojure/West talk in March. [1] https://github.com/clojure/test.check [2] https://github.com/reiddraper/simple-check -- 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/groups/opt_out.
Re: [ANN] clojure.test.check (previously, simple-check)
Congrats Reid, thanks a lot for all your work on this! Have only been using simple-check for a little while now, but it's already paid big dividends in production. One of the most concretely useful testing tools I've ever used. For folks that haven't tried it, I'd absolutely recommend taking a look. Great stuff. Cheers! :-) - Peter -- 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/groups/opt_out.
Re: [ANN] clojure.test.check (previously, simple-check)
Hey Andrew, Good question. tl;dr, change your test to: (tc/quick-check 100 prop1 :max-size 50) ;; and that should pass. Longer explanation: test.check's generators take two parameters, a random number generator, and an integer 'size'. During testing, the size starts at 0, and increases up to some fixed maximum. This is used to that the 'size' of the generated data increases as more and more tests pass. The rationale here is that you don't want your very first to generate a million-length vector, when, if there is a bug, its more than likely also present with 'smaller' data. As it turns out, with a complex generator like gen/any, a size of 100 (the default maximum) can generate very large, nested data-structures. This is explained in some detail in the documentation [1]. I've tried to make all of the built-in generators have sane defaults, but its appear like gen/any can still generate massive, nested structures with the default values. I'll look into a more sane default sizing strategy for this generator. As I mention in the tl;dr above, you can set the maximum 'size' used during testing. [1] https://github.com/clojure/test.check/blob/master/doc/intro.md#recursive-generators On Feb 28, 2014, at 3:41 AM, keeds akee...@gmail.com wrote: Hi Reid, This is excellent. Just experimenting and trying to get my head around it. Not sure if I'm doing any wrong or stupid!! If I test a function that relies on Exception handling internally as I reach 100 tests it takes forever and eventually blows the heap. Simple contrived example: (ns check (:require [clojure.test.check :as tc] [clojure.test.check.generators :as gen] [clojure.test.check.properties :as prop] )) (defn format1 [x] (try (- (double x) (format %,.0f)) (catch Exception e ))) (def prop1 (prop/for-all [v gen/any] (string? (format1 v #_ (tc/quick-check 100 prop1) ;; blows heap Thanks, Andrew On Thursday, 27 February 2014 17:22:44 UTC, Reid Draper wrote: I'm happy to announce the first release of the newest Clojure contrib library: test.check [1]. Previously named simple-check [1], test.check is a property-based testing library, based on QuickCheck. The README has a guide for migrating from simple-check, as well as some getting-started documentation. I'm happy to answer any questions here as well. Or, stop by my Clojure/West talk in March. [1] https://github.com/clojure/test.check [2] https://github.com/reiddraper/simple-check -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/EPNoH4JEiVQ/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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/groups/opt_out.
Re: [ANN] clojure.test.check (previously, simple-check)
Congrats! Ambrose On Fri, Feb 28, 2014 at 1:22 AM, Reid Draper reiddra...@gmail.com wrote: I'm happy to announce the first release of the newest Clojure contrib library: test.check [1]. Previously named simple-check [1], test.check is a property-based testing library, based on QuickCheck. The README has a guide for migrating from simple-check, as well as some getting-started documentation. I'm happy to answer any questions here as well. Or, stop by my Clojure/West talk in March. [1] https://github.com/clojure/test.check [2] https://github.com/reiddraper/simple-check -- 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/groups/opt_out. -- 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/groups/opt_out.
[ANN] clojure.test.check (previously, simple-check)
I'm happy to announce the first release of the newest Clojure contrib library: test.check [1]. Previously named simple-check [1], test.check is a property-based testing library, based on QuickCheck. The README has a guide for migrating from simple-check, as well as some getting-started documentation. I'm happy to answer any questions here as well. Or, stop by my Clojure/West talk in March. [1] https://github.com/clojure/test.check [2] https://github.com/reiddraper/simple-check -- 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/groups/opt_out.
