>> 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. 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 <julia...@yahoo.com> 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 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. > > > -- “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.
