yep in terms of composition.
On Mon, Aug 3, 2009 at 9:17 PM, Shane Courtrille <[email protected]>wrote: > 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 > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
