0

For unit testing is it better to mock the data layer or use an embedded database like derby?

I know that it also depends on the purpose of the testing. But if I go with derby I don't have to mock all the objects and I assume that would be easier. On the other hand I understand that that is more towards integration testing. So which one is more common for unit testing?

Thanks.

Update according to comments:

So I have derby configured now but my manager insists on using easymock. We are using jpa and we have about 20 tables => data models. So then for each method like for project model should I specify the return type of the mockedProject for all its methods? Like getProjectName(), getProjectId(), etc? And also should I mock the persistent manager object. I thought that is just a lot in comparison with just configuring an embeded db like derby.

Sara
  • 2,417
  • 7
  • 35
  • 52
  • Your update is technically another question, so just few words. You should not mock value objects (I assume `Project` is an entity). Instead mock behaviours. With JPA mocking `EntityManager` should be enough. – Tomasz Nurkiewicz Jul 18 '12 at 21:58
  • More detailed question : http://stackoverflow.com/questions/11551905/unit-testing-a-method-with-easymock – Sara Jul 18 '12 at 23:34

3 Answers3

3

First of all if you use external components in unit tests (like database, file system, etc.) they can no longer be called unit tests, but integration tests instead.

On the other hand quoting the classic Mocks Aren't Stubs says:

  • Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).

And there's nothing wrong in using fakes in unit tests.

That being said I advice using some fast and simple in-memory database like . Mocking DataSource, Connection, ResultSet, PreparedStatement... is just not worth the pain.

See also

Community
  • 1
  • 1
Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
  • The question is not on unit testing the data layer, so you would not need to mock all the internals of it, only the layer it self for testing other parts of the code using it. – Jacob Midtgaard-Olesen Jul 18 '12 at 21:48
2

For unit testing I would recommend mocking your data layer. This makes it clear that you are not testing the functionality of the data layer and it also increase the speed of the unit test.

When doing an integration test you should have a live database connected to your data layer, I prefer to use the same type of database as is used in production to limit the risk of new errors being introduced later on. Also I recommend to let each test build its own test data and remove it afterwords as this ensures that each test is not affected by interaction with test data in other test cases.

Jacob Midtgaard-Olesen
  • 161
  • 4
1

If you're using JPA, you don't need to mock your Project objects, because they are probably just dumb POJO's, right? What you need to mock is just the persistence manager object (EntityManager). In the simplest case (if you're using Mockito or Easymock with 'niceMock') you may just need to create the mock and inject it and that's it. Depending on what you're testing, you will probably want to do more than that: verifying that a save or merge method is called, specifying that it is to return a particular Project object on a get call, etc.

Mocking the EntityManager has several benefits:

  1. It runs very fast - much faster than even an embedded database. These tests are going to be run many many times, so it's important that they not be too much of a burden.
  2. You don't need to populate a real database. Although you might need to do that anyway for some integration tests, it's hard to come up with a database that covers all of the scenarios that you want. With mocking, you can create the specific scenario you want right in the test itself.
  3. You may want to test certain conditions that would be very difficult to make happen in reality, such as IO errors or data that already exists in the database but that violates some constraints. With mocking, you just tell the mock to throw an exception when the method is called. Connecting to a real database (even embedded) it would be very difficult (if not impossible) to make it happen.

Mocking a POJO has none of these benefits. It's just as fast to execute the code of a POJO as a mocked POJO. Populating a POJO can be a bit of a pain, but not as much as setting up the behavior of a mocked POJO. And since POJO's don't (normally) have much in the way of external dependencies, the third benefit is rarely required.

jhericks
  • 5,833
  • 6
  • 40
  • 60
  • Thanks a lot. This is what I was looking for. I am not much familiar with mocking. I ll post another question and past the link here. Would appreciate if you could take a look at that later on. Thanks. – Sara Jul 18 '12 at 23:15
  • Could you take a look at this one if you had time : http://stackoverflow.com/questions/11551905/unit-testing-a-method-with-easymock – Sara Jul 18 '12 at 23:35