The original intent of mock objects was to use it as an aid to identify and discover roles in your application domain, mocking everything will simply lead to very brittle and unmaintainable tests, in the long run they hinder the evolution of the design. A unit test doesn't necessarily mean you have to test every single object in complete isolation, you need to distinguish between internal objects and peer objects. You would not want to mock internal objects, On the other hand we should ensure we are not hiding the wrong information inside an object. Well-designed objects should be context independent and not tied to its environment, i wrote about this here http://isaiahperumalla.wordpress.com/2009/06/08/designing-inter-object-protocols-using-mocks/
Things like ensuring that the persistence layer and your repositories working correctly I would simply use an integration-test to verify its behavior, using some lightweight in-process db like sqlite or sql ce I agree, while unit tests help with the internal quality of the software, it does nothing to ensure external quality of the system. Thats why its vital that you have end-to-end test which ensure all the pieces actually work together. In fact I start development with an end-to-end failing test and then let that drive the development. Steve Freeman and Nat Pryce one of the pioneers of mock objects are writing a book. I found this very useful. you can find the draft here www.mockobjects.com/book and http://mockobjects.com/book/ongoing.html cheers Isaiah On Mon, Aug 3, 2009 at 5:11 AM, Shane Courtrille <[email protected]>wrote: > Also... > > > http://www.amazon.com/xUnit-Test-Patterns-Refactoring-Addison-Wesley/dp/0131495054 > > Is very helpful for learning how to handle common test smells.. > > > > On Sun, Aug 2, 2009 at 10:07 PM, Shane Courtrille < > [email protected]> wrote: > >> Actually I'd agree with your manager. A "Unit Test" does not touch >> anything external. Everything should be mocked out when "unit" testing. >> >> BUT... >> >> Unit testing is only 1/2 the battle (and I now strongly believe the less >> important half of the battle). Integration testing where you connect all >> your little pieces together and have them work end to end (including >> databases and web service calls) is critical to the safety and security of a >> software development project. When done properly unit tests come and go as >> the individual units are refactored and sometimes even replaced but it is >> the integration (regression, smoke, whatever) tests that survive and prove >> that the entire system still continues to operate. >> >> On Sun, Aug 2, 2009 at 2:43 PM, Tom Whittaker <[email protected]> wrote: >> >>> >>> I have a development manager who wants us to mock almost every single >>> component our software change interacts with because he insists that >>> we are suppose to completely isolate our unit test from other >>> components, which is what he calls a unit test. >>> >>> We keep telling him that is not how to write unit tests, but he is the >>> manager, and so we've been doing it this way. >>> >>> For example, I agree with the following web page's "Reasons for use" >>> of mocks. >>> >>> http://en.wikipedia.org/wiki/Mock_object >>> >>> Does anyone have the argument that supports the extreme position our >>> manager is taking? Or better yet, a good book or paper that argues >>> against this extreme? >>> >>> From what I've been seeing, it has created poorer quality software >>> because we are actually not finding bugs that use our real databases >>> and external web services until very late in the process. We just had >>> a feature freeze date, and we found a few major problems that day >>> largely because everyone was using mocks, and the mocked systems did >>> not behave the way our mocks did, and the higher level functional >>> tests created by QA missed a few things that a normal unit test would >>> of caught had we not been using mocks for everything. >>> >>> >>> >> > > > > -- Isaiah Perumalla --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/RhinoMocks?hl=en -~----------~----~----~----~------~----~------~--~---
