It appears you are trying to hand-craft your DAO mocks. Over time this can get very tedious and difficult to maintain because not only will you have to maintain your production code and the tests for them, you'll also have to maintain your hand-crafted mocks. This also adds complexity that I don't think is really necessary.
If you define an interface for your DAOs and use a mocking framework like Mokito, you can have Mokito manage your mock DAOs for you. Then you can concentrate on the parts of the tests that you should be: the test data and the assertions that you want to make. Unit tests need to run very fast and they shouldn't cross any execution boundaries like having to read the file system or access a database or access a Web Service. I suggest you keep your test data/mock data in your test classes (this is in reference to another thread you started).
No, there's no problem. Well my objective with this is to learn how to do Mocks. That's why I'm not using any framework... Anyway if you saw the getList method that I showed in the previous post, I'm passing a "Integer ls" as a parameter. I'm doing this wrong because I'm not using it. How would you do this?
If you want to learn how to use the mock objects technique properly, I suggest that you don't try to write hand-crafted Mocks because that's almost like saying "I want to learn how to drive a car" then going out to the hardware store to buy parts so you can build your own car. Way too much work and way too complicated.
Daniel Afonso wrote:No, there's no problem. Well my objective with this is to learn how to do Mocks. ...
If this is the objective then reading a book like has been suggested is much better than starting many threads for the same problem in the forums.
Another mistake you might already have made is starting with some DAO that may or may not be testable.
If you wrote your test cases first you would have been forced to write testable implementations. This is a good thing because testable code is reusable code.