(Happy new year all!) I have thousands of lines of tests written using Midje and it was the second one I turned to when I started using Clojure full-time a couple of years ago. I think it would be fairer to say that Midje is powerful enough to hang yourself, but that doesn't make that power wrong. This is the good old power/not power dilema and caution should dfefinitely be used by newbies using Midje, particularly established OO developers to ensure they don't mis-use Midje's tools as a bridge to stay in the OO paradigm.
Having said that, I don't use midje anymore simply because of the IDE support. I did encounter some minor issues (like gettings facts working in macros for example) but that was almost certainly my issue and if I stayed on the "beaten track" as it were it was a delight to use and rock solid. I gotta say Timothy, I think you are coming across a bit strong - it might not float your boat, but you need to back up "abomination". At the moment you risk people writing off your experience as "mis-used the tools, got in a mess and then blamed the tools" which would be a shame as your "paradigm shift/mental model" point is valid. Brian - Midje rocks - keep up the good work ;). On Saturday, 3 January 2015 15:39:08 UTC, tbc++ wrote: > > >> 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 > <javascript:>> 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 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/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.
