On Dec 11, 2010, at 12:16 AM, ka wrote: > Hi Brian, > > Can you explain this in more detail : > >>> I didn't have the laziness problem. I don't know if that was by accident or >>> because Midje applies an #'eagerly function before checking. > > Because it seems that if code has a laziness problem, Midje will > actually hide it in tests?
It's something like the same situation as Ken Wesson described. Looking at my tests, here's one case: (fact (f 1) => [1 2 3 4 5] (provided (g 33) => 5)) The call to g produces the fifth value, 5. It turns out that (f 1) returns a lazy seq whose first value is wrong. That means the fifth value is never computed. That means (g 33)=>5 was never used, though we claimed (f 1) depended on it. The user gets a misleading test failure. So instead of passing the results of ((call-map :function-under-test)) to the checking function, I pass the results of (eagerly ((call-map :function-under-test))) That makes for less confusion, except perhaps for people who're working with truly infinite seqs. For example, suppose the test were (fact (f 1) => (some-value-less-than 5)) Then an implementation of fact that was (repeatedly (constantly arg)) would silently spin forever. ----- Brian Marick, Artisanal Labrador Contract programming in Ruby and Clojure Author of /Ring/ (forthcoming; sample: http://bit.ly/hfdf9T) www.exampler.com, www.exampler.com/blog, www.twitter.com/marick -- 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
