>> Hacker News notwithstanding, "idiosyncratic interface" is not a synonym for abomination.
True, however, reaching into code, and re-deffing a function's definition is. Not only is it not thread-safe (removing the possibility of ever running two tests in parallel), but it also hides main problem. If you need to use Midje's "providing" you wrote your code wrong. If your only way to test a given bit of code is to re-deff a var, then that var should be abstracted into a different component. Because at the end of the day, I don't care if 'foo' makes a call to 'bar', all I really care about is that 'foo' saves data to 'baz'. Stuff like with-redefs and providing muck with a developer's mental model of the source code. So instead of being able to say "well foo calls baz here, so this should work". They have to think "well foo calls baz unless someone re-deffs it, in which case I haven't a clue what's going to happen, so let me go check every test that calls foo, or calls something that calls foo to make sure it isn't overriding baz somehow". >> Lots of people use Midje for production code without your problems. Not in my experience. I've used Midje in two fairly large codebases (not including mine, on these I was brought in as a consultant). And not only were the tests brittle (doing simple refactoring to the codebase would break many tests unrelated to that code, and that weren't really bugs at all), but the developers themselves mentioned more than once that they wish they had gone with a simpler testing framework. So perhaps that is the problem. Midje is "easy", but not "simple". New Clojure developers pick up Midje because it has all the bells and whistles, but they lack the experience to use it properly, and so they end up with unmaintainable code. And so I assert that a simpler library, something that only provides deftest, assert and run-tests forces developers to think about the best way to test something, and to write their own macros (as patterns emerge). But hey, don't take my word for it, run a poll, see what users of Midje think and would like to see. Include the factors I mentioned above (# of years using Clojure, # of years using Midje, do they still use it, etc). Timothy On Fri, Jan 2, 2015 at 6:55 PM, Brian Marick <mar...@exampler.com> wrote: > > > Timothy Baldridge wrote: > >> I don't recommend Midje at all. Many of the framework's mocking >> facilities (such as providing) are abominations. >> > > Hacker News notwithstanding, "idiosyncratic interface" is not a synonym > for abomination. > > It may look cute, >> but I've lost countless hours to bugs and unexpected behavior related to >> Midje. >> > > An example would be handy right about now. > > As the author of Midje, I protest. Lots of people use Midje for production > code without your problems. I've been using on production code for coming > on two years now. > > C'mon: all of the main Clojure testing frameworks are opinionated, each in > different ways. They're all perfectly competent at what they do. They don't > hide bugs. They all have deterministic behavior. None of them are all that > complicated. > > >> The pattern I do recommend is to break your system up into components. >> Each component should be testable by mocking its dependencies and then >> testing only that component. In a final test, stitch together all your >> components and run system tests against all components at once. >> > > I think this is good advice. > > > -- > 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. > -- “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/d/optout.