I think that it should *not* be added, for the same reasons given already; I think it's much better to have a smaller API surface, and one that encourages best practice. Also it's worth noting that you can use AssertWasNotCalled(), which gets much closer to what you really want; In your example you said that you wanted a and b to be called and not c, therefore I'd say it's better to specify these on a granular level rather than only a and b can be called; what happens when you add method d that has no side-effects and costs nothing to call, why would you want the test to fail if d is called?
On Tue, Apr 14, 2009 at 4:37 PM, Tim Barcz <[email protected]> wrote: > Take a look at Repeat.Never() > > Unless someone has some additional strong objections to this, I would be > okay with adding this. (Note to others, chime in now if you want your voice > heard) > > Tim > > > On Tue, Apr 14, 2009 at 10:33 AM, Peter Morris <[email protected]>wrote: > >> >> > While I understand the need/desire for strict mocks (believe me I do). >> > You >> > can do assertions that something is never called on a dynamic mock which >> > gives you similar behavior. >> >> By using .Throw or some other technique? >> >> >> Pete >> ==== >> http://mrpmorris.blogspot.com >> http://www.AlterEgos.com - Who do you want to be? >> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
