People have different philosophies, but here's mine: Test your code through a very few stable interfaces.
I would *not* isolation test each function. If you make small functions and you want to refactor (inline and extract duplication), isolation testing will make things difficult. If you choose stable interfaces that can reach the entire system, you'll have better luck. Occasionally, there will be a small function or piece which it makes sense to test in isolation. Perhaps it will have a stable and well-understood interface, but the implementation is complicated or tricky. What happens next is that people notice (or complain) about the large amount of variation which needs to be pushed through the interface, and they start to have long tests as they build data. The solution here is another piece of perfectly fine wisdom that is counter to some popular wisdom: Extract duplication and abstractions from the tests to create a library that expressively drives your application (cf. "DRY code, wet tests"). This works super well in Clojure. -Jason P.S. This is Detroit-style TDD - mock very rarely at the edges of the system; test through a few interfaces; slop code in, make it work, then make it pretty, extract and remove duplication; in other words, "make the design simpler through refactoring." This is opposed to London-style TDD - test each component in isolation using mocks, keep tests wet, use testing pain to tell you that you have too many dependencies or are making bad APIs, work top down, and have separate integration tests to tell you the system works. People argue the merits of each, but the worst thing happens when they are confused and someone tries to do Detroit with wet tests or isolation, or London with ... refactoring? (That might be disingenuous–not my school). A note: London is usually about making simple object hierarchies and I don't think it can apply to Clojure. On Thu, Mar 3, 2016 at 6:11 AM, Timur <timurha...@gmail.com> wrote: > Hi all, > > I generally create composable functions that depend on certain keys of an > input map and compose them using threading macros. However testing > functions separately is somehow cumbersome as each fn depends on the output > of another one. > > How do you test these? What is the best way to test them using Midje? Any > examples will be appreciated... > > Regards, > > Timur > > -- > 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/d/optout. > -- 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/d/optout.
