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.
The intent is to specify a set of inputs to the method invocation to force it down a particular codepath, then verify the outputs either as a return value, or that methods interaction with passed parameters. Maybe someone can provide an example of the behavior you are talking about that might become incorrect. Craig? Martin? I'd appreciate some insight here.
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.
Yeah, you're specifying how the objects should behave during this test. That's the same as Shale Test Framework, except that common top level concepts are pre-initialized during TestCase.setUp(). Interestingly, the jMock mock objects are verified implicitly, so there's no need to call (or forget to call) mock.verify(). 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!
The assertions that jMock gives you are more complete than what you have used before with EasyMock. For example, one can say that the parameters don't matter, but that the return value should always be the same. Btw, I'm interested to know more about how we plan to test our own code too. tc, -john.
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://apress.com/book/bookDisplay.html?bID=10044 Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
