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.