No if it can be done in Unit tests
The answer however is not a yes / no as this is not really a binary choice.
When possible use Unit tests. If you are testing 'based on this information from this interface...", i.e. business logic, then you can mock or stub that interface to provide that specific data for that condition.
In many organizations not all services can easily be mocked however and there are inter relationships that can't easily be avoided. Using programmatic approaches to mock and stub services, set up proxy servers, etc. also requires technical knowledge that may not be present in the organization, especially within many traditional testing organizations.
In these cases I recommend following two principles:
- Use the Agile testing pyramid as a guide to the volume of test cases
- Focus on happy/positive tests and a small number of sad/negative integration test cases
I recommend that each time you want to test business logic, you follow the route of
- many unit tests for positive and negative cases
- some integration tests to make sure systems can talk to each other
- some integration tests to make sure systems can handle other system being down
- fewer automated UI tests to ensure the end user experience works
- a small amount of exploratory testing to catch unknowns and stay humble
Remember that the point of integration testing is specifically to test the integration between systems and is needed because unit tests use mocks and stubs.
One approach for integration tests is for them to simply verify the method signatures (names and params) for the public methods and interfaces to ensure they have not changed. This can be done without complex integration tests requiring domain knowledge.
Another approach is to actually use the same set of tests with one run using mocks and stubs to run in unit test mode, the other run using real dependencies. This can have the advantage of less maintenance.
One point of note for integration tests is that they test the interface between systems - or sometimes between parts of the same system. Their data can be from the real interfaces, or from an interfaces that you supply ('data for pre-made answers'). When you control the interface you may be able to use grey box testing where you can create data conditions you need, by faking out the service and providing the response. The main consideration here is that foreign systems will eventually change and sometimes it will be unknown / unexpected / unannounced and usually seem to be at the worst time. This is why a combination of tests for both fake and real sources may be the best solution.
See What is really tested in an integration test?
See How to do integrated testing?
See What's the recommended practice for separating unit tests from integration tests for automated testing?