Comments on: Mocker 0.10 and trivial patch-mocking of existing objects http://blog.labix.org/2007/12/09/mocker-010-and-trivial-patch-mocking-of-existing-objects by Gustavo Niemeyer Thu, 21 Aug 2008 10:39:59 +0000 http://wordpress.org/?v=2.5.1 By: Gustavo Niemeyer http://blog.labix.org/2007/12/09/mocker-010-and-trivial-patch-mocking-of-existing-objects#comment-25594 Gustavo Niemeyer Mon, 07 Jan 2008 13:39:55 +0000 http://blog.labix.org/2007/12/09/mocker-010-and-trivial-patch-mocking-of-existing-objects/#comment-25594 Yes, and no. For sure I'd recommend against doing it if there are better alternatives (in most cases there are). But notice that there is a whole thread of testing which advice more than only checking input and output (see Mocks Aren't Stubs). Also, in case of non-idempotent methods, input/output may not be enough. With that in mind, Mocker offers the feature. It's up to the developer to understand when it's a good idea and when it's not. Yes, and no.

For sure I’d recommend against doing it if there are better alternatives (in most cases there are).

But notice that there is a whole thread of testing which advice more than only checking input and output (see Mocks Aren’t Stubs). Also, in case of non-idempotent methods, input/output may not be enough.

With that in mind, Mocker offers the feature. It’s up to the developer to understand when it’s a good idea and when it’s not.

]]> By: Patrick Altman http://blog.labix.org/2007/12/09/mocker-010-and-trivial-patch-mocking-of-existing-objects#comment-24929 Patrick Altman Thu, 03 Jan 2008 14:52:57 +0000 http://blog.labix.org/2007/12/09/mocker-010-and-trivial-patch-mocking-of-existing-objects/#comment-24929 Cool tool. However, isnt your use case invalid from the point of method encapsulation in that we should only be concerned with the results of a method call not how that method goes about its work to produce the results. The caller should depend on the "how" a method works only what inputs are and what expected outputs should be. No? Cool tool.

However, isnt your use case invalid from the point of method encapsulation in that we should only be concerned with the results of a method call not how that method goes about its work to produce the results. The caller should depend on the “how” a method works only what inputs are and what expected outputs should be.

No?

]]>