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 Thu, 11 May 2006 04:45:15 GMT
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'd appreciate as much help as I can get reworking the ADF Faces test
suites to be based on the Shale test framework - assuming we agree on
the approach, of course!

-- Adam


On 5/10/06, Dennis Byrne <dennis@dbyrne.net> wrote:
> The test suites for myfaces core and tomahawk were refactored for the shale test framework.
 A *lot* of easymock and mockobject code, some aspect dependencies, and dozens of incomplete
api/pojo classes were removed.  By the time I was done I had actually removed more code than
I had ever committed to the project.  There is no learning curve for this stuff and it's in
ibiblio.
>
> Dennis Byrne
>
> >-----Original Message-----
> >From: Adam Winer [mailto:awiner@gmail.com]
> >Sent: Wednesday, May 10, 2006 08:43 PM
> >To: adffaces-dev@incubator.apache.org
> >Subject: Re: Thoughts about unit testing and mock objects
> >
> >JMock does look interesting, but a couple of basic questions:
> > - Is it available in a maven repository?
> > - Is its license compatible?
> >
> >... and one more general one.  The thing that drives me up the
> >wall with the current mock codebase in the ADF Faces tests
> >is that it forces you to say "I expect method foo() to be called
> >at least N times", even though with JSF there's rarely any
> >such assurances whether a method will be called or not,
> >and if so how many times.   E.g., how often is FacesContext.getViewRoot()
> >called?  Once?  Twice?  20 times?
> >
> >This leads to extremely brittle tests that are a mess to write
> >and understand.
> >
> >So, to be more brief:  does JMock fix this awfulness, or perpetuate
> >it? :)
> >
> >-- Adam
> >
> >
> >On 5/10/06, John Fallows <john.r.fallows@gmail.com> wrote:
> >> The recent delivery ADF Faces codebase with the missing jsf-mock dependency
> >> got me thinking...
> >>
> >>    - "Do we really need hand-written (or possibly generated) mock
> >>    implementation classes as a dependency?"
> >>    - "What strategy should we follow for our own classes that require
> >>    mock implementations?"
> >>
> >> For future test development, we might benefit from using jMock which doesn't
> >> require a separate set of mock class implementations to mock the interfaces
> >> / abstract classes.
> >>
> >> http://jmock.codehaus.org/getting-started.html
> >>
> >> Interestingly, jMock can leverage CGLib to manage dynamic proxy creation of
> >> abstract classes, and produces extremely readable unit tests that capture
> >> the semantics of the code being tested.
> >>
> >> Does anyone have jMock or mock object experiences to share?
> >>
> >> tc,
> >> -john.
> >> --
> >> http://apress.com/book/bookDisplay.html?bID=10044
> >> Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
> >>
> >>
> >
>
>
>

Mime
View raw message