Unit testing by mocking the data layer or using embedded database

问题

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.

回答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:

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.
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.
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.

回答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.

回答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 h2. Mocking DataSource, Connection, ResultSet, PreparedStatement... is just not worth the pain.

Unit testing by mocking the data layer or using embedded database

问题

回答1:

回答2:

回答3:

See also