On 5/14/06, John Fallows <[EMAIL PROTECTED]> wrote:
On 5/13/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
>
>
> In an example that ought to be relevant for this codebase :-), consider
> what
> happens when you want to test the encodeBegin(), encodeChildren(), and
> encodeEnd() methods of a Renderer implementation. The methods return
> void,
> so the output isn't particularly interesting :-). What is interesting,
> however, is that the methods themselves are going to assume that
> FacesContext.getResponseWriter() returns somethng usable, even in a unit
> test scenario. Shale's MockFacesContext, for example, gives you back a
> mock
> writer that can write out to a buffer, which you can later examine to
> determine whether the component created correct markup or not (based on
> the
> properties/attributes you set on the component). And, this functionality
> is
> needed in all renderer tests, so it makes sense to encapsulate into a
> separate library that can be debugged once.
>
> How do you approach this sort of scenario with dynamic mocks?
Nice example, thanks Craig!
With dynamic mock objects, you would setup each method call made on the
ResponseWriter which is functionality equivalent, although much more
verbose.
Far more so, to the point that I can hardly imagine anyone writing a test like
that. Also, the order of invocations becomes partially important,
and partially irrelevant - which attributes are written on which
elements are important, which order the attributes are written
is irrelevant. A dynamic mock is never going to have enough
semantics to capture this requirement.
That's why the ADF Faces codebase has a handwritten mock for
a response writer that very intentionally *is not* the same response
writer we use at runtime:
http://tinyurl.com/m4zth
... and there's no way that the default mock implementation would
capture any of the semantics that this test captures.
Your point is to simplify the effort involved in verifying the result,
right? That's pretty useful, although this example doesn't appear to
address my question about the behavior that might become incorrect.
Simplifying the effort to write a test is crucial, not just pretty useful.
Developers are habitually lazy at writing tests, and putting obstacles
in their path ensures they won't.
For your question about "behavior that might be incorrect",
say I was mocking UIComponent behaviors for a piece of code
that will need to invoke findComponent(). How do I mock
findComponent()? Odds are, if I'm writing the test, I mock it
to produce exactly the result I want - not necessarily implement the
correct algorithm. Do I know that my test is right?
-- Adam
