This is one of the main reasons why I try to stay clear of heavy use of invasive mocks. I can't tell you the amount of times I've looked at code and realized that because of mocks nothing was really being tested at all. Instead, think of mocks as the terminator in a test chain. That is to say, they only exist to allow the program to continue executing. Tests should only validate the behavior up to the call to the mock'd function, no further. Otherwise you're testing your mock, and that causes all sorts of problems (as you discovered).
I don't recommend Midje at all. Many of the framework's mocking facilities (such as providing) are abominations. You shouldn't go around mucking with functions and re-deffing them on the fly. It may look cute, but I've lost countless hours to bugs and unexpected behavior related to Midje. IMO, stay clear of that. 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. If you do what Ashton suggests and use temporary databases, this will work quite well. This way you get the detailed errors of unit tests when things fail inside a component, as well as contractual tests between components. I highly recommend Stuart Sierra's Component Library for all of this: https://github.com/stuartsierra/component It forces you to define the dependencies of each component, and so mocking or stubbing out a component is almost trivial. Timothy Baldridge On Wed, Dec 31, 2014 at 8:13 AM, Ashton Kemerling <ashtonkemerl...@gmail.com > wrote: > I've always done the full database setup and tear down thing, but that's > made sufficiently performant with datomics in memory store. Consider using > transactions to isolate tests, or use Midje, which is more designed for > this kind of usage. > > --Ashton > > Sent from my iPhone > > On Dec 31, 2014, at 9:48 AM, Jonathon McKitrick <jmckitr...@gmail.com> > wrote: > > I use TDD and mocking/stubbing (conjure) to test each layer of my code. > The problem is when I change the function signature and the tests do not > break, because the mocks/stubs do not know when their argument lists no > longer agree with the underlying function they are mocking. Is there a way > to catch this? Short of a test suite that eschews stubbing in favor of > full setup/teardown of DB data for each test? > > -- > 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. > -- “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.
