Clean Architecture use case testing

Question

Use case interactors in the Clean Architecture consists of the application specific business rules.

Interactors uses the Data Access Interface to fetch the required data from the data access layer.
Basically I see two approaches to test these interactors.

• Using test doubles rather than the actual data access layer
• Using the real data access layer (e.g. sql database, webservice)

I personally prefer the first approach and test the data access layer seperately.
The interactor tests uses the Data Access Interface with the test doubles and the entities in the inner circle.
An architectural boundary is crossed in both approaches.

Is the first test approach considered as Integration Testing with a narrower scope or is it just Unit Testing?

Answer 1

or is it just Unit Testing?

There is nothing "just" about Unit Testing.

The distinction between Integration Testing and Unit Testing seems to be different in every shop. However, the most useful distinction I've ever found doesn't come from Uncle Bob. It comes from Michael Feathers:

A test is not a unit test if:

• It talks to the database
• It communicates across the network
• It touches the file system
• It can't run at the same time as any of your other unit tests
• You have to do special things to your environment (such as editing config files) to run it.

Michael Feathers - A Set of Unit Testing Rules

Under this definition, to unit test a Use Case Interactor you need to stop talking to the database. A fake or stub can do that nicely.

It's worth understanding that the second approach is still testing. It's just testing more and doing it slowly. It's still a good test. But it's not a test that should be mixed with your unit tests. Unit tests work best when they all run quickly. Not when they're mixed with slow tests.

You might also be wondering, if only the database is stub/faked is the rest an integration test? Well this is the grey area. If you consider an integration test anything that tests how two things integrate then yes, this is an integration test between interactor, entities, input, and output. But, while that's literally true it's not a very useful distinction.

This would also count as a unit test since you can take all those things as parts of the unit under test. I prefer this view. I don't like the view that a class is the only valid unit.

For me, the most useful distinction between tests is not structural, it's speed. I like the fast ones in one pile and the slow ones in another pile. That way I can run them separately. I tend to call the fast ones unit tests and the slow ones integration tests. But whatever you call them the point is to have two different piles of tests. That way you can run them at different times.

I like to be able to run all my unit tests about as often as I type a semicolon.