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 <[EMAIL PROTECTED]> wrote:
On 5/12/06, John Fallows <[EMAIL PROTECTED]> wrote: > On 5/12/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > > On 5/12/06, John Fallows <[EMAIL PROTECTED]> wrote: > > > > > > 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 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
