incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek" <martin.marinsc...@gmail.com>
Subject Re: Thoughts about unit testing and mock objects
Date Sat, 13 May 2006 21:47:21 GMT
I do believe as well that jMock doesn't provide enough context for
writing proper tests of JSF-behaviour.

At leasts whatever tests I have written so far needed some more than
just a method to call and the information on whether this method has
been called.

regards,

Martin

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.
>
> >  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
> >
> >
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Mime
View raw message