On Mar 19, 11:08 pm, Stuart Sierra <the.stuart.sie...@gmail.com> wrote: > Hi Frantisek! > > I can see where this is useful, and the only reason I haven't > implemented something like it for a test-is already is that I don't > expect it would be very commonly used outside of the very specific > case of testing the language itself. Where else, other than a language > specification or a math library, are you going to be testing every > combination of arguments? > > Secondly, remember that tests are just functions, with a little extra > metadata. I thought about allowing them to accept arguments, but then > I didn't know how to call them in run-tests. But you can define > ordinary functions and use them in your tests. It turns out to be > pretty easy to define all-all are this way: > > (defn all-are [pred & args] > (doseq [[x y] (combinations args 2)] (is (pred x y)))) > > (deftest equality > (all-are = 0 0.0 0M 0/1) > (all-are #(and (= %1 %2) (not= (class %1) (class %2))) > (sorted-map :a 1) (array-map :a 1) (hash-map :a 1)))
Very nice! This will improve readability and ease the writing of the tests! I will remember to create a new function if needed. > The only disadvantage to this is that you won't get some of the nice > error reporting features, like individual line numbers, that you get > when you use "is" by itself. But you would have the same problem if > all-all are were a macro. I like to see the line numbers, but it isn't anything necessary. Usually, figuring out what went wrong, is much harder. > So I guess, overall, I'm saying you shouldn't feel limited to using > just the basic constructs that the library provides. They're just > building blocks for your own, larger abstractions. If there's a > particular abstraction that shows up repeatedly in lots of different > contexts, then I'll want to add it to the library. I agree with keeping the core small. > As for the fate of "are", I've always been a little uncertain about it > because it relies heavily on the templates library. And I've always > been uncertain about templates because they rely heavily on code > walking and code transformation. For example, in early versions of the > lazy branch, "are" didn't work, and I never could figure out why. > Fundamentally, I think anonymous functions are a more robust > abstraction than templates, and my future work will probably rely more > on functions than templates. Still, several people have said they > like "are", so I wouldn't drop it lightly. I don't like too many library dependencies and it is something to watch for. I haven't given any deep thoughts about how to improve 'are', but its utility is great. Since 'all-are' depends on 'combinations', we just gonna have to keep this organism healthy from the bottom to the top :-) Thanks for the help, Frantisek --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
