incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: Thoughts about unit testing and mock objects
Date Sat, 13 May 2006 23:49:33 GMT
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?

Craig

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