>> 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?
You're right, my bad. I just looked at the Speclj docs as it's been some time since I used the framework. I forgot that "with" defines a new var that is passed in to the functions. I like that approach. Seems like I saw a demo once that used with-redefs, but I'm probably hallucinating. Timothy On Mon, Jun 10, 2013 at 9:11 AM, Colin Jones <trptco...@gmail.com> wrote: > > > 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> 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 >>> >>> 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 >>> >>> For more options, visit this group at >>> http://groups.google.com/**group/clojure?hl=en<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. >>> >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<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. > > > -- “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.
