I agree with your comments about other examples using lists since they didn’t reflect Martin Fowler’s discussion about the ‘subject under test’ as distinct the collaborator (http://martinfowler.com/articles/mocksArentStubs.html), in list examples I think they have collapsed the ‘subject under test’ and collaborator together as one in order to showcase mockito easier but this cause confusion about the right technique when mocking.

I am not sure where Spring is coming in here, that’s why I was looking at your article in the first place(google, “Spring and Mockito”), your example is a straight Mockito test i.e. there is no Spring dependency injection (maybe I have the wrong end of the stick?)

None the less, a good Mockito example.

TestData.createTestProfile(“userid”); Here still we are incurring some manual labour to create a class and method to return us a profile and to me it looks like not mocking completely, but may be in future what I would like to have is that you just specify the data somehow and get the object created. Thanks

I would split the “testRead” method in several methods testing only one behaviour, for example “testEmptyReadThrowsInvalidProfileException” and “testValidReadReturnsCorrectDto”

I would also test that an exception is thrown using @Test(expected=YourException.class): see http://junit.sourceforge.net/javadoc/org/junit/Test.html#expected() and http://junit.sourceforge.net/doc/cookbook/cookbook.htm (at the end of the page) for an example.

Although I don’t get why you would write something like

assertEquals(1, 2); // should never execute

You could change it to make it a bit more understandable
http://junit.sourceforge.net/javadoc/org/junit/Assert.html#fail(java.lang.String)