incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: Thoughts about unit testing and mock objects
Date Sat, 13 May 2006 16:09:13 GMT
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.

>  Then, the unit test reads as
> "setup expectations", "execute real object method", and "verify actual
> behavior".

And here's Objection #2:  "setup expectations" is not a natural programming
model.  It requires defining criteria in a meta-programming language so
that "verify actual behavior" becomes simply a call to a mock "verify()"
method.  Anything that isn't in this meta-language is either impossible or
requires writing custom critierion objects which is tedious and verbose.

And, my main Objection #3: most tests (not all, but most) that I write
in JSF are not concerned with testing the behavior of the JSF objects.
That is, I rarely care about testing how I invoked FacesContext or
UIComponent or ViewHandler.  So the assertions that the mock frameworks
give me - method foo() was called once with certain parameters - don't
actually help me very much!

-- Adam


> The unit test verifies that the method behaves according to the expected
> semantics defined in the same method.  With a minimal amount of expected
> behavior to specify in each unit test method, the general approach does not
> seem that error prone to me.  Perhaps some of this setup just needs to be
> hoisted out of the unit test method in special cases, like Shale does for
> JSF specification objects.
>
> Lastly, I think that the best way to verify in-container behavior is to run
> the code in the actual container and update the isolated behavior
> specifications in any unit test methods that need to be improved.  When the
> tested codepaths are working, the unit tests will ensure that they keep
> working.
>
> Thanks for any insights you can provide to help me figure out the pros and
> cons here. :-)
>
> tc,
> -john.
> --
> http://apress.com/book/bookDisplay.html?bID=10044
> Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
>
>

Mime
View raw message