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 04:25:17 GMT
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 ...

tc,
> -john.


Craig

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