The problem with having unit tests that don't properly insulate the sut from other pieces is that you can very quickly lose one of the big benefits of unit tests which is error localization. When you talk about internal objects do you mean in terms of composition? If so then I agree completely but if you mean internal to a subsystem then I don't. The individual pieces of a subsystem still may require isolation during testing. While brittle tests are a concern when we talk about mocking I am starting to become a firm believer that the brittle tests may be more a sign of problems with the code (law of demeter, ask don't tell, srp) then with the usage of mocks.
All that said occasionally I do find myself using direct objects in tests when their behavior is very simple but I'm not 100% comfortable with this On Aug 3, 2009 2:37 AM, "isaiah perumalla" <[email protected]> wrote: 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... > ... Isaiah Perumalla --~--~---------~--~----~------------~-------~--~----~ You received this message because you are su... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
