incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Fallows" <john.r.fall...@gmail.com>
Subject Re: Thoughts about unit testing and mock objects
Date Sun, 14 May 2006 18:15:12 GMT
On 5/13/06, Craig McClanahan <craigmcc@apache.org> wrote:
>
> On 5/13/06, John Fallows <john.r.fallows@gmail.com> wrote:
> >
> > On 5/13/06, Adam Winer <awiner@gmail.com> wrote:
> > >
> > > On 5/12/06, John Fallows <john.r.fallows@gmail.com> wrote:
> > > > On 5/12/06, Craig McClanahan <craigmcc@apache.org> wrote:
> > > > >
> > > > > On 5/12/06, John Fallows <john.r.fallows@gmail.com> wrote:
> > > > > >
> > > > > > On 5/10/06, Adam Winer <awiner@gmail.com> wrote:
> > > > > > >
> > > > > > > I thought more about this over the last few hours.  I think
my
> > > basic
> > > > > > > gripe with easymock and mockobject approaches to JSF API
> objects
> > > is
> > > > > > > that most of the JSF tests I write rarely are
> > > concerned  specifically
> > > > > > > with testing how my code is interacting with the JSF
> API;  it's
> > > how my
> > > > > > > code is itself behaving.  The former is where mock object
> suites
> > > pay
> > > > > > > dividends, but when your main concern is in your own code,
> mock
> > > suites
> > > > > > > seem to get in the way for more than they help.  Basically,
> the
> > > Shale
> > > > > > > test framework seems like a better fit (yeah, handcoded,
but
> > that
> > > > > > > work's done and released...).
> > > > > >
> > > > > >
> > > > > > I don't understand your point.  Shale test framework is founded
> on
> > > mock
> > > > > > objects.
> > > > >
> > > > >
> > > > > In addition, code we write in things like ADF Faces is going to
> > assume
> > > > > certain behavior on the part of the JSF runtime -- I like to use
a
> > > mock
> > > > > object framework that behaves enough like the "real thing" so that
> I
> > > can
> > > > > test the parts of my code that depend on that behavior too, not
> just
> > > > > static
> > > > > unit tests on individual methods.
> > > > >
> > > > > Also, no one so far seems to have addressed the second question in
> > the
> > > > > > original post about how we should provide mock objects for our
> own
> > > code
> > > > > in
> > > > > > our unit tests.
> > > > >
> > > > >
> > > > > It probably blurs the line between unit tests and system
> integration
> > > tests
> > > > > a
> > > > > bit, but I like to use the real objects, rather than mocks,
> whenever
> > I
> > > can
> > > > > feasibly do so.  Besides having to do less work (not building
> mocks
> > > for
> > > > > classes that can be used both at test time and runtime), this also
> > > reduces
> > > > > the risk that I will mistakenly program my own class to the
> possibly
> > > > > botched
> > > > > behavior of a badly written mock object, giving me a false sense
> of
> > > > > security
> > > > > when the tests pass ...
> > > >
> > > >
> > > > Well I definitely agree about not wanting to hand-craft mock object
> > > > implementations!
> > > >
> > > > Dynamic mock creation also seems to address that by not requiring an
> > > > implementation and keeping the recipe for the behavior isolated to
> the
> > > unit
> > > > test itself.  This provides self-documenting tests which are
> > especially
> > > > useful for anyone trying to learn the semantics of the code.
> > > >
> > > > IMHO, unit testing is about verifying the semantics of each codepath
> > in
> > > each
> > > > method, aiming for 100% coverage.  This is most easily verified if
> > each
> > > > codepath is unit tested in isolation, preventing cascading failures
> > and
> > > > minimizing initialization overhead (only create the objects used by
> > the
> > > > method codepath).
> > > >
> > > > The point about false positives is interesting.  Let's assume that
> we
> > > don't
> > > > have any reusable mock object implementations to possibly botch,
> > instead
> > > we
> > > > have a specification of expected behavior (to possibly botch!)
> inside
> > > each
> > > > unit test method definition (using jMock).
> > >
> > > This is, I guess, Objection #1 for me.  Why put the burden of defining
> > > proper JSF behavior into every test, instead of into a reusable mock
> > > implementation?  It's not just a question of effort - it's one of
> > > correctness,
> > > since if that behavior can be independently defined in each test, it
> > > can be defined differently in each test.
> >
> >
> > The intent is to specify a set of inputs to the method invocation to
> force
> > it down a particular codepath, then verify the outputs either as a
> return
> > value, or that methods interaction with passed parameters.
> >
> > Maybe someone can provide an example of the behavior you are talking
> about
> > that might become incorrect.  Craig?  Martin?  I'd appreciate some
> insight
> > here.
>
>
> 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.

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.

tc,
-john.
-- 
http://apress.com/book/bookDisplay.html?bID=10044
Author: Pro JSF and Ajax: Building Rich Internet Components, Apress

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message