Макет ненужных компонентов React с помощью Jest

Question

Давайте представим, что у нас есть этот Page компонент:

const Page = () =>
  <>
    <Topbar />
    <Drawer />
    <Content />
  </>

Я бы хотел протестировать некоторые взаимодействия внутри Drawer и Content компонентов в интеграционном тесте с монтированием нашего Page компонента, поэтому я бы написал макет для компонента Topbar , потому что он мне не нужен, с:

jest.mock('./Topbar', () => {
  const TopbarMock = () => null
  return TopbarMock
})

Тогда наши тесты не будут визуализировать этот компонент, увеличивая его время выполнения, и он менее подвержен сбоям из-за некоторой ошибки, внесенной в него, изолирующей нашу функцию.

У меня проблема в том, чтокаждый раз, когда мне нужно добавить новый компонент в компонент Page , я должен делать то же самое, что я делал для Topbar .

Мой вопрос: есть лилюбой способ указать компоненты, которые вам понадобятся для этого интеграционного теста, а не те, которые вам не понадобятся (как раз наоборот).Примерно так: для этой функции, которую я сейчас тестирую, мне просто понадобятся компоненты Drawer и Content , так что больше ничего не визуализируйте.

Или есть ли лучший способ написания интеграционных тестов без насмешек?

Answer 1

В Enzyme такой функциональности нет, потому что это необычная стратегия тестирования.

Распространенная стратегия тестирования заключается в том, чтобы иметь широкий охват модульных тестов и менее ограничительные тесты E2E.Интеграционные тесты могут быть добавлены к чувствительным единицам, которые требуют большего внимания.

Нецелесообразно одинаково насмехаться над всеми компонентами.В сценарии искусственного тестирования может сработать имитация произвольных компонентов с помощью () => null, но в реальном сценарии это может вызвать проблемы в родительском компоненте, поскольку он может ожидать, что дочерние элементы будут вести себя иначе, чем неактивный компонент.

Тестированиевсе возможные взаимодействия между единицами в интеграционных тестах приведут к слишком большому количеству пар.Необходимость сделать это означает, что юнит-тесты не являются тщательными.Такие интеграционные тесты приводят к большой дополнительной работе с небольшой ценностью, поскольку они не учитывают возможные взаимодействия между несколькими устройствами.Смежные юниты могут иметь значение, которое приведет к провалу теста.

В этом случае достаточно провести юнит-тест для Page, который выполняет мелкий рендеринг и утверждает, что это 'тупая' оболочка для Topbar,и т. д. Дети могут пройти тестирование в соответствующих модульных тестах.