I would disagree with "Test should be treated like any client code and should never know the internal details of the object under test". If you don't know the internal how can you ever do
- Expect.Call.Time.Never - Assert.WasNotCalled - Assert.WasCalled - etc you HAVE to know the internals of the SUT in order to do some types of testing. Remeber, there are two types of testing which mocking helps with 1. State based tests 2. Interaction based Stubs shine with state based tests providing canned results, but to really DO interaction based tests you need mocks and knowledge of the internals of the method. Agree? On Mon, Mar 23, 2009 at 11:24 AM, isaiah perumalla < [email protected]> wrote: > This is an interesting topic i had many discussions recently. > > >>>While developping a web interface we first focussed on implementing > >>>the basic edit functionality.This meant that our strict view moq knew > >>>a registration to the EditClick event would happen. > > >>>- Then we moved on to the next feature, which included subscribing to > >>>the SaveClick event. Because this extra subscription all our tests of > >>>the first feature failed because they were not expecting that extra > >>>event subscription. Is this extra subscription a concern in our tests > >>>for the first feature? I have the feeling that it shouldn't matter. > If mocks are used for that then i would agree strict mock will cause you > problems. > The argument for dynamic mock is that Strict mocks is often a design smell, > because tests to express knowledge of an operation's internals, and does not > allow for easy refactoring. > To me this is a design issue with the code undertest, the brittleness of > the test is a symptom of a weakness in the design. To me it means that the > object is exposing its internal details, its not encapsulating its internal > interactions. Test should be treated like any client code and should never > know the internal details of the object under test. When i have a brittle > test first thing i do is check to see if i'm specifying interactions > concerned with implementation. > I mainly use mocks to discover roles in a system so i can create and design > role interfaces, which consist mainly of command methods. > eg receiptReceiver.Expect(x => x.ReceiveTotalDue(3.Dollars)); > I rarely use dynamic mocks, since i mainly use mock to design interactions > between objects and very the indirect output. > Normally i start with an end-to end failing test and work my way in. > In your case i guess you using MVP with webforms and you dont have a higher > level end to end test to start with so in this case you need something like > a dynamic mock, when you testing that something subscribes to some event. > > > > > On Mon, Mar 23, 2009 at 1:12 AM, Tim Van Wassenhove < > [email protected]> wrote: > >> >> In my experience strick mocks lead to overspecification. >> >> Here is a real life example: >> >> -While developping a web interface we first focussed on implementing >> the basic edit functionality.This meant that our strict view moq knew >> a registration to the EditClick event would happen. >> >> - Then we moved on to the next feature, which included subscribing to >> the SaveClick event. Because this extra subscription all our tests of >> the first feature failed because they were not expecting that extra >> event subscription. Is this extra subscription a concern in our tests >> for the first feature? I have the feeling that it shouldn't matter. >> >> That was the point were i started to choose dynamick mocks by default, >> and strict mocks when required. >> >> Greetz, >> Tim >> >> > > > -- > 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 -~----------~----~----~----~------~----~------~--~---
