Tim yes that what I'm saying I see 2 thread-off here
1) having interaction-based tests with mocks that are sensitive enough to catch errors/bugs and insensitive enough not to break at every small refactoring 2) having mock framework powerful enough to easily mocks objects and basic enough to let the developer fill the code design smells from the TDD point of view , the #2 is by far the most important. I would say that 8 times out of 10 when an interaction-based test is fragile it is a smell that - in the object under test there is inappropriate responsibility coupling , or - the object under test is interacting with too low-level objects or it is exposing internal low-level implementation details the other 2 times, once mocks where used for input or state testing instead of stabs and the other a hand coded mocks will do the job (better then complicated mock tool features) for #1, there are objects (like simulation objects or math/statistic objects) that change their global state from every single methods, because of this a dynamic mock will be too insensitive of bugs. since you cannot predict the evolution of your objects I feel a little dangerous the use of dynamic mocks On Mar 23, 1:36 am, Tim Barcz <[email protected]> wrote: > If I may summarize...I believe you are saying that the dynamic mocks create > more brittle tests than tests where strict mocks are used (CreateMock in > previous versions of RhinoMocks). > I resonate with what you are saying. I held this view for some time as I > felt that strict mocks were more "correct". As someone who has used > RhinoMocks for a few years I can say that I understand the move to deprecate > CreateMock. I found through our experience that our tests were far more > brittle using strict mocks. You mention agile and feedback loops and > failing fast. What I found is that our use of strict mocks did now allow > for easy refactoring, another highly held agile principle. The issue I see > with "failing fast" and strict mocks is that often the failing tests are > really just false positives. > > If you're concerned something might be called that shouldn't be...you can > always test for specific scenarios...ie. say AssertWasNotCalled or > Expect().Times.Never > > Very interested in hearing your thoughts and others. > > Timhttp://www.twitter.com/timbarcz > > On Sun, Mar 22, 2009 at 6:52 PM, (luKa) <[email protected]> wrote: > > > Ciao from Stockholm, > > > I'm reading this > > >http://ayende.com/wiki/Rhino+Mocks+3.5.ashx#CreateMockisdeprecated,re... > > and I've noted that dynamic mocks can lead to flawed tests. > > > Going on with the example in the link, suppose that with the evolution > > of the sw the method RevertUserChanges() is added to the > > IUserRepository interface. > > Then a dev introduce a bug in the LoginController.ForgotMyPassword() > > so that RevertUserChanges() get called by mistake. > > As I understood the Dynamic Mock now wont raise an error because of > > this call to RevertUserChanges(). > > > I feel that brittle tests are a smell for responsibilities that must > > be decoupled instead of a need for object dynamically mocked. What you > > think ? > > when I think about exception I see a similarity, I prefer to get the > > exception instead of running the risk of catching and ignoring an > > important problem. > > > The agile principle here is feedback and fail fast > > > Luca Minudel > > Stockholm, Sweden GMT+1 > >http://www.linkedin.com/in/lucaminudelen-GB > >http://blogs.ugidotnet.org/luKa/it-IT --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
