20 messages in org.apache.incubator.adffaces-devRe: Thoughts about unit testing and m...| From | Sent On | Attachments |
|---|---|---|
| John Fallows | May 10, 2006 5:23 pm | |
| Adam Winer | May 10, 2006 5:43 pm | |
| Dennis Byrne | May 10, 2006 6:29 pm | |
| Adam Winer | May 10, 2006 9:44 pm | |
| Craig McClanahan | May 10, 2006 10:09 pm | |
| John Fallows | May 12, 2006 9:08 pm | |
| Craig McClanahan | May 12, 2006 9:15 pm | |
| John Fallows | May 12, 2006 9:16 pm | |
| Craig McClanahan | May 12, 2006 9:24 pm | |
| John Fallows | May 12, 2006 10:12 pm | |
| Craig McClanahan | May 12, 2006 10:32 pm | |
| John Fallows | May 12, 2006 11:43 pm | |
| Adam Winer | May 13, 2006 9:08 am | |
| Martin Marinschek | May 13, 2006 2:46 pm | |
| John Fallows | May 13, 2006 3:44 pm | |
| Craig McClanahan | May 13, 2006 4:49 pm | |
| John Fallows | May 14, 2006 11:14 am | |
| Adam Winer | May 14, 2006 12:35 pm | |
| John Fallows | May 14, 2006 9:47 pm | |
| Matthias Wessendorf | Jun 19, 2006 3:31 pm |
| Subject: | Re: Thoughts about unit testing and mock objects | |
|---|---|---|
| From: | Craig McClanahan (crai...@apache.org) | |
| Date: | May 10, 2006 10:09:54 pm | |
| List: | org.apache.incubator.adffaces-dev | |
On 5/10/06, Adam Winer <awi...@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'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 <den...@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:awi...@gmail.com] Sent: Wednesday, May 10, 2006 08:43 PM To: adff...@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...@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