It's just a little issue, but one that pops up in my mind regularly when writing test scripts.
Imagine you have an application which does some car tax calculation, having a REST service which has a method for calculating the tax and an HTML interface with a screen to enter the required input and display the tax to pay. The HTML interface makes uses of the REST service and does nothing more than some input validation, passing the values to the REST interface and then display the tax to pay.
Let's assume you developed several service tests for the REST service, e.g. using SoapUI, some with invalid input (weight=0kg or price=€0) and one with valid input (weight=900kg, price=€25000).
The HTML interface is tested for usability, browser compatibility and other relevant quality attributes, which do not apply for the service test. The system test, e.g. using Protractor, contains some test cases concerning input validation, like an empty field for the weight of the car. You also want to verify if the tax calculation displays the correct amount to pay for valid input. Would you use the same test data as used in the service test, because you have the expected results already available, or would you deliberately choose different test data in order to implicitly test the business logic more thoroughly?
Let's assume two situations:
You know the unit tests concerning the tax calculation have a coverage of about 80% and you know the developers are aware of techniques like equivalence partitioning. A decent base for the test pyramid.
The unit tests concerning the tax calculation have a coverage of just 40% and there is no time and budget to write more unit tests and raise the coverage, unfortunately, a common situation.
In the latter situation, you could, of course, extend the service tests to increase coverage on a higher level, but even then you have to decide if you want to deliberately use different input values for the system test.