It looks to me that you're mixing up 2 types of testing here: unit testing and integration testing.
With unit testing, you're testing a single unit. Now what the definition of a "Unit" is differs from which developer you ask it to. Some will say a unit is a single class, other will say it's a single method. I've even met developers who group an entire module as a single unit. In my opinion a unit is a single method of a class that you are testing.
The most important part of testing a single unit is that you want to simulate the environment surrounding it. That is: the dependencies of the class. This is called mocking. For example: if you're testing a single unit that needs to process some output of a database, you don't want to perform an actual query on a live database; you'd rather mock the database dependency to make sure that for your test it will always return a certain set of data.
Integration testing is one step further and once again, it's definition depends on which developer you ask it. In my opinion: with an integration test you test the integration between multiple units. We've already tested our units as stand-alone entities, now it's time to see how well they work together.
An integration test is often heavier than a unit test, because it mostly requires an active installation (with testdata) and it does not allow much for mocking. With integration tests you make use of fixtures. A fixture is a pre-defined state / set of data that is present for the test to work on. For example: if you want to test a product filter that filters on a products' status, a logical fixture would be to have a set of 5 products with different statuses.
Integration tests often also do their own setup and teardown to populate and delete a test-database. The Magento 2 integration test framework is a good example of this.
Needless to say, an integration tests uses far more processor power and memory consumption because it's often tested in a real installation. In a CI/CD street, it makes perfect sense to run unit tests on merge requests / commits, and to run integration tests on a deployment (or on set times / cooldown periods).
So to answer your question: use mocking for your unit tests, but not for your integration tests. Mocking should always be done when your class/method uses external dependencies.