On 5/10/06, Adam Winer <[EMAIL PROTECTED]> 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'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!
I'll try to throw in a bit of time on this (haven't got the newly dropped code to build yet, but that shouldn't take too much more work). But, in particular, if anyone finds anything in the test framework that is incompletely implemented, or you need more flexibility in configuring the framework's mock objects, feel free to ping me (either here or on the Struts dev list). As an example of this, I just added the ability for the mock request/session/ServletContext objects to fire attribute added/removed/replaced events like a container would do it. Craig -- Adam
On 5/10/06, Dennis Byrne <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > >Sent: Wednesday, May 10, 2006 08:43 PM > >To: [email protected] > >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 <[EMAIL PROTECTED]> 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 > >> > >> > > > > >
