Конечные React Компоненты

А почему бы в решении со слотами не внедрять через props определения компонентов вместо их экземпляров? А для тестирования можно использовать defaultProps:

import Aside from "./Aside";

const Page = ({ Aside, ...props }) => (
  <section>
    <Aside />
    <main>bla bla bla...</main>
  </section>
);

Page.defaultProps = { Aside }; 

import Page from "./Page";
import AsideContainer from "./AsideContainer";

const PageContainer = props => <Page {...props} Aside={AsideContainer} />

Тогда презентационные компоненты действительно не зависят от контейнеров.

Из всех вариантов понравились только первое и последнее решения (мокать). Те которые подразумевают ровно 0 строк кода в реальной кодовой базе проекта, оставив все финты ушами в коде тестов и их окружения. Сам прибегаю к unit-тестам для react-компонент очень редко, предпочитая интеграционные. Ворочается это медленно (особенно ввиду того, что enzyme написан ногами), но даёт какую-то веру в реальную полезность этих тестов.

Юнит тесты это тестирование в изоляции от внешних зависимостей. Компонент компоненту — зависимость. shallow годная штука при наличии явной вложенности. Когда разработчику становится скучно и он начинает изобретать новые способы для связи компонентов, с тестами тоже приходится заморочиться.

Для меня неудобства с enzyme и shallow render начались когда я перешел от такого паттерна

class ItemsList extends React.Component {
   renderItem(item) {
       return <li>{item.name}</li>
   }
   render() {
     return <ul>
       {this.props.items.map(item => this.renderItem(item))}
     </ul>
   }
}

к вот такому

function Item({ item }) {
  return <li>{item.name}</li>;
}

class ItemsList extends React.Component {
  render() {
    return (
      <ul>
        {this.props.items.map(item => (
          <Item item={item} />
        ))}
      </ul>
    );
  }
}

Разбиение на более мелкие компоненты упрощает рефакторинг, делает код более понятным, но усложняет тестирование, потому что shallow render не рендерит содержимое <Item />. Нужно либо писать отдельные тесты для Item, либо использовать dive.

Мое ожидание от хороших тестов это то, что они не требуют к себе внимания и не ломаются после таких небольших рефакторингов. mount показывает здесь лучшие результаты.

Проблемы внутренних компонентов у меня решалсь моками: jest.mock('react-router-dom', () => ({Link: FakeLink})) – и готово.

C проблемой "бесконечной" вложенности контейнеров не сталкивался, потому что не вижу смысла писать unit-тесты на верхнеуровневые конейнеры, типа DashboardPage. Проще протестировать блоки этой страницы по отдельности, которым нужно меньше моков, а потом написать несколько вебдрайверных тестов на страницу целиком.

Штука изолированная от внешнего мира — это компонент, а не модуль. Модуль — это по определению кусок исходного кода, изолированный от других кусков исходного кода.

Адепты Реакта предпочитают не замечать следующих косяков в его дизайне:

1. Вычисляемые в момент передачи пропсы. Это не позволяет делать их вычисление ленивым и автоматически трекать зависимости компонента. В результате, чтобы обновить попсы компонента нужно перерендерить компонент уровнем выше. Ну и к прочим проблемам типа поднятия всего дерева, хотя нам в данном тесте интересны только 2 точки в нём.
2. Берущиеся из локальной области видимости классы/функции компонент. Это не позволяет их подменять извне. Это нужно не столько для тестов, сколько для настройки сторонних/обобщённых компонент под себя/конкретное место использования.

Отсюда и все ваши проблемы — 100500 костылей, как сделать очередную базовую функциональность.