In the tutorial, I can understand why it's confusing. In the example, you're not really testing anything but that a method is being called. You might think this is silly, but it's actually saved my ass in the past. Also, what happens when your one-line method turns into a 200-line one that talks to EJBs on another server and a web service on a legacy system. It's nice to be able to mock those dependencies. Overengineering? Possibly.
We should probably add some verbage to explain it more. Testing with mocks makes a lot of sense in a few cases: 1. You want speed. 2. You want to test a single class, not it's dependencies. 3. You want to test business logic in a method. 4. You want to segregate development teams. #1. This is pretty obvious - not connecting to a database or initializing Spring will be very fast. #2. If you write an "integration" test instead of a mock test, changes are you'll be doing the same thing as the DAO test does, except you'll be verifying the Spring wiring is correct. With integration testing, the class you're testing is often like a black box, where you put in inputs and expect outputs. With mock testing, you have a bit more control and can set expectations on dependencies to make sure methods are called and such. #3. This doesn't make much sense until your managers have lots of business logic. Of course, integration tests on a manager with one-line methods is similar in its usefullness. Of course, there's nothing stopping you from writing integration tests for managers. In fact, there's a BaseManagerTestCase to do just that. See UserManagerTest.java for an example: http://static.appfuse.org/appfuse-service/xref-test/org/appfuse/service/UserManagerTest.html #4. If you have a UI team that wants to be decoupled from the backend, you can provide them with interfaces they can mock. Then they don't have to be concerned about the backend - they can tell it what they want it to return. Spring AutoMock (http://sourceforge.net/projects/automock) could be useful as well - allowing you to mock out the backend when running in a servlet container. At least, I think that's the functionality it provides. Hope this helps, Matt On 9/19/07, Martin Homik <[EMAIL PROTECTED]> wrote: > > I do understand that mocks are useful to imitate a certain behaviour of > compononts which are sort of resource-demanding. But, I don't get the value > of using jMock for testing Managers as it is used in the tutorial. Let me > pick a test method: > > > public void testFindByLastName() { > log.debug("testing findByLastName"); > > List people = new ArrayList(); > String lastName = "Smith"; > > // set expected behavior on dao > dao.expects(once()).method("findByLastName") > .with(eq(lastName)) > .will(returnValue(people)); > > List result = manager.findByLastName(lastName); > assertSame(people, result); > } > > As far as I understand it, I am telling the mock (for PersonManagerDao) that > if a method "findByLastName" is invoked with a parameter "lastName", then it > should return the empty ArrayList "people". In a second step the manager > just invokes this method and the mock returns "people" which is stored in > "result". Now, comparing "people" with "result" does not make much sense and > unsurprisngly both lists must be the same. It looks like the following > conversation: > > ME: "If I ask you for your name then answer 'Arthur'. So what's your name?". > Arthur: "My name is Arthur." > ME: "You're right." > > I have the deep impression that I misunderstand something, but I am unable > to identify my knowledge gap. Can anyone help and explain jMock's use in the > tutorial? > > I can imagine to use jMock in the following way: I have some method which is > doing some computation which depends on information being stored in a > database. Let's assume I want to calculate the length of someone's first > name. Then with jMock I can simulate the database's behaviour. But, instead > of testing the retrieval function, I want to test the computation. Any idea > what the test would look like? > > Cheers, > Martin > > -- > View this message in context: > http://www.nabble.com/jMock-in-Tutorial-not-self-explaining-tf4481302s2369.html#a12778467 > Sent from the AppFuse - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- http://raibledesigns.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
