Service layer testing: Is it still unit testing when using dbUnit and not mocking a native Spring domain layer?

Question

I have a service layer and a domain layer. I use plain native Spring repositories for the domain layer and in my test setup I'm mocking the db with dbunit.

@Repository
public interface ExampleRepository extends PagingAndSortingRepository<ExampleEntity, Long>, JpaSpecificationExecutor<ExampleEntity> {
}

Naturally I will assume that the Spring repository implementation has no errors and therefor the domain layer is no subject to tests.

My general knowledge about unit testing is that I would need to mock my domain layer when writing unit tests for my service layer.

With my assumption that the domain layer does not need to be tested, and the with the fact, that I use dbunit to mock my database, am I allowed to use this setup for unit tests of my service layer?

Answer 1

If I understood it correctly, in your tests the Spring context is boostraped, your service layers is tested along with your domain layer, and the data is inserted in your test database using DBUnit.

With that, let's start:

My general knowledge about unit testing is that I would need to mock my domain layer when writing unit tests for my service layer.

If you want to do a Unit Test, then this is correct. The way you describe your tests, it depends on both layers to be correct, and the DB must be running so, per definition they are integration tests.

With my assumption that the domain layer does not need to be tested, and the with the fact, that I use dbunit to mock my database, am I allowed to use this setup for unit tests of my service layer?

I wouldn't call the use of DBunit a database mock. It surely helps populating the database, but the DB is still needed to run the tests, and your domain layer will be executed (JPA, Hibernate or whatever ORM framework will be generating SQLs that will be executed against the DB). If you really want to mock the domain layer and the DB then you should consider using mocks (many mock libraries can help with that).

As for the final question, well if this setup is working for your project I suppose it's OK, but I just wouldn't call it Unit Testing, but Integration Testing. You'll have to accept that if your domain layer for some reason changes, it will probably break your service layers tests.

There are pros and cons on both approaches (unit vs integration). If it helps you grow your project with quality and good maintainability, then there is no "right" or "wrong" approach.

Answer 2

No, testing with dbUnit is integration testing.

• Unit testing involves only the small unit of code under test with mocking of any additional interactions.
• Integration testing involves a broader scope of the system with an external service, such as testing SQL with a database server and sending an email using email server. In both cases, we use "test doubles" instead of the real production ones to verify the system correctly interacted with the external service.

There are many test types, and the most common I see and implement are unit, integration, acceptance, and performance. All are valuable and have different pros/cons. It's best to have all types for a quality system.