What are the separations of concerns for testing a component that consumes additional components

When writing tests for a web-component (parent) that consumes other web-components (children) should the parent's tests provide coverage to ensure the children are rendering/configured properly?

Here's an example, it might be a poor example, but's lets try: Say we have a component (WebComponent/React/Vue/Ember, any component will do here): <Carousel @options=options> which renders various children components: such as <Video @options=options> and <Image @option=options> and many others.

The Carousel component receives a set of options from the model, such as iconColor and objectFit, and passes that in a datadown fashion to share with and be consumed by the child components.

Should I be testing “user can configure iconcolor for image” in both my tests for the <Image> and <Carousel>?

It seems awkward to me and not very DRY to test for successful configuration of iconcolor in the respective tests for both <Carousel> and <Image>. If the <Carousel> component consumes 5 different components, its tests start scaling in size, especially if we add more config options.

But at the same time is seem very brittle not to have test coverage in both. For example, if we rely on <Image>'s test coverage for configuration of iconColor, <Image> could be refactored anytime and a developer could change the name of the property for setting iconColor, adjust the tests to match. The developer would be unaware that <Carousel> has a dependancy on <Image>'s API for configuring iconColor.