On Monday, June 10, 2013 9:20:31 AM UTC-5, tbc++ wrote: > > >> 1) testing recursive functions. I want to test what a recursion STEP > does, not the >> whole function. Can I mock 'recur'? > > You shouldn't need to, pull the body of the loop out as as separate > function, then test that function. > > >> 2) testing sequence, esp. lazy > > For this, I often create a generator function, or do what I suggested for > 1). If your code is functional you should be able to test subsets of a lazy > seq by supplying the correct arguments to your generation function. > > >> 3) IoC typically makes code more testable. What are Clojure > alternatives for IoC? Pass all dependencies as parameters to your function? > > That's exactly what you should do. Functions should be small enough to > only need a few dependencies. If they need more, consider putting them into > a hash-map. > > Some systems like Midje or Speclj have systems for helping with this, but > I have only ever been frustrated with them. In the case of Speclj, > var-redefs are prefered, which assume that you'll have global vars to hold > your state, which is exactly the behavior I try to avoid. > > You can certainly use with-redefs with any testing library/framework, or you can pass dependencies into your production-code functions. I think perhaps I'm missing the detail you're seeing on how using a particular test framework encourages using global vars - can you elaborate?
> Midje on the other hand, is a massive pile of macros and DSLs that > so complicate your code that advanced tests are insanely hard to debug. Pop > Quiz: Midje's "fact" and "provided", how are those parsed and executed? I > don't know! It's a black box, and I'd have to go and read the codebase to > understand why they don't work the way I think they should. Because Midje > exposes tests in a custom DSL, you can't approach it as if it was Clojure, > it's a different language with different semantics. > > I want my tests to be in the same language as my code, this is why I tend > to stick with clojure.test. What are tests? Functions. What are assertions? > a simple wrapper around "assert". Simplicity at its finest. Sure, the > library is a bit underpowered, but I've never been frustrated with > clojure.test. And I can't tell you how many dozens of hours I've lost > trying to figure out why Midje doesn't like my test results. > > Oh, and lein-difftest....that's one awesome bit of code. It provides extra > information, and yet doesn't add needless complexity. > > Timothy > > > On Sun, Jun 9, 2013 at 11:22 PM, julianrz <juli...@yahoo.com <javascript:> > > wrote: > >> This may be a little off topic, but does this, or any other framework, >> solve some testing inconveniences that exist in Clojure and probably other >> functional languages: >> 1) testing recursive functions. I want to test what a recursion STEP >> does, not the whole function. Can I mock 'recur'? >> 2) testing sequence, esp. lazy >> 3) IoC typically makes code more testable. What are Clojure alternatives >> for IoC? Pass all dependencies as parameters to your function? >> >> I wonder if code=data philosophy of Lisp enables some testing techniques >> that are impossible in languages like Java. Typically you can only test a >> function programmatically, not arbitrary code block. But you can probably >> introspect code very easily in Clojure, and test parts, regardless if they >> are functions or not. A test framework could support that in principle... >> >> I found that functional code is harder to separate, which would make it >> harder to test... >> >> Any thoughts? >> Thanks, >> Julian >> >> -- >> -- >> 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/groups/opt_out. >> >> >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > -- -- 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.
