0

So for my unit testing I am using easymock. I have a findProject method which queries the db and returns a list of the projects. I have mocked the object which returns the entityManger(I am using JPA and Hibernate). So it is something like : mockedRepository.findList() which returns the projectList. So now that is a mocked object. So in these situations I cannot check the return value of findList. Right? Cuz that is a mocked object and it just returns what I want. So if you want to test this kind of methods which query the db we cannot use mocking. Right? I can just check whether the methods have been called with easyMocking. Right?

Thanks.

Sara
  • 2,417
  • 7
  • 35
  • 52
  • Yes, of course you can check the return value of a mocked object, just as though it were a "real" DB object. The whole *point* is that the object you're testing shouldn't *know* or *care* whether the underlying object is "real" or "mocked". – paulsm4 Jul 19 '12 at 18:35
  • Hmms so I thought when I define a mocked project object and then I say : Easymock.expected(mockedProject.findList).andReturn("somehting"); Then it would return whatever, I have defined.. If I don't define that return type then inside that method it calls entityManger.getQuery("sth").getResultList() and because there is no actual db there it would throw an exception. Even if I don't mock that method and mock entityManger itself then it would return whatever I have defined. Right? Then in general I cannot test a real return value of db with easymock, cuz it is just a mock. Right? – Sara Jul 19 '12 at 18:45
  • underlying object here is entityManger which calls db. My whole point is that for this type of methods which just query db, mocking is not a solution. Am I right? – Sara Jul 19 '12 at 18:46
  • EasyMock just enables you to call your methods, and it doesn't capture their implementation. Am I right? – Sara Jul 19 '12 at 18:47
  • 1
    Q: EasyMock just enables you to call your methods, and it doesn't capture their implementation. Am I right? A: Yes :) And that's a Good Thing, for purposes of a) development, and b) testing. – paulsm4 Jul 19 '12 at 21:48
  • 2
    Q: for this type of methods which just query db, mocking is not a solution. Am I right? A: Yes. If you want "real" data, you should call the "real" database. – paulsm4 Jul 19 '12 at 21:50

3 Answers3

2

I would recommend to use a simple in-memory Java SQL database, like H2 or HSQL. Instead of mocking.

yegor256
  • 102,010
  • 123
  • 446
  • 597
1

you have at least two options:

  1. create your own instance EntityManager using Persistence.createEntityManagerFactory("persistence_unit_name").createEntityManager() and use it in your stubs or inject in objects under test.
  2. use something like jpa-unit which does it for you.

I personally use 2nd option for every query in my projects. I use this library to test if queries execute without any parse exception or something. Some time ago I tried to test whether queries return what I itended them to return (this lib also helps you with setting up db and filling it with test data - like dbunit) but since it was to troublesome I gave up on it.

assylias
  • 321,522
  • 82
  • 660
  • 783
Tomasz Krzyżak
  • 1,087
  • 8
  • 10
1

So if you want to test this kind of methods which query the db we cannot use mocking. Right?

Right.

Tom Anderson
  • 46,189
  • 17
  • 92
  • 133