как протестировать стороннюю библиотеку компонентов в react-testing-library

Question

У меня есть компонент реакции, который импортирует компонент из другой сторонней библиотеки (например, Ant или bootstrap), и теперь я хочу протестировать поведение этого компонента onClick.

Однако это трудно getByTestId или getByText, потому что сторонняя библиотека не имеет атрибута thiese или иногда не имеет текста в теге html. Как я могу получить сторонний дом и протестировать его с помощью библиотеки response-testing?

PS: некоторые могут сказать, что нам не нужно тестировать компонент bootstrap, потому что это их бизнес, но это снизит нашу тестовое покрытие. (например, если мы передаем много реквизитов функций обратного вызова в качестве обработчиков событий компоненту a bootstrap, мы должны протестировать обратный вызов, чтобы увеличить тестовое покрытие)

Answer 1

Библиотека тестирования React была разработана, насколько я понимаю, для написания тестов, основанных на опыте пользователя с визуализируемыми элементами. Со сторонними компонентами это иногда может быть обременительно.

Я думаю, что есть несколько подходов:

1. Просмотрите шпаргалку библиотеки тестирования React и спросите себя, как пользователь понимает элемент в первую очередь. Может в данном случае дело в роли элемента? Т.е. содержит ли ваш сторонний компонент свойство aria, определяющее роль для этого компонента?

Пример: приложение использует кнопки из bootstrap

const App = () => {
  const [state, setState] = useState(0)

  const increase = () => {
    const newState = state + 1
    setState(newState)
  }

  const decrease = () => {
    const newState = state - 1
    setState(newState)
  }

  return (
  <div>
    <div className="App">
      <Button variant="primary" size="lg" onClick={increase}></Button>{' '}
      <Button variant="primary" size="lg" onClick={decrease}></Button>{' '}
    </div>
    <div className="number">
      {state}
    </div>
</div>
  )
}

Я намеренно не предоставлял текст для кнопок, но я все еще могу найти эти кнопки, вот тест:

it('buttons increase and decrease displayed value', () => {
     const component = render(<App/>)
     const buttons = component.getAllByRole('button')

    for (let i = 0; i < buttons.length; i++){
      fireEvent.click(buttons[i])
    }

    expect(component.findByText('0')).toBeTruthy()
})

Несмотря на то, что я не мог установить testId или найти по тексту, я все же мог собрать массив узлов, которые воспроизводят роль кнопки. Оттуда нужно выполнить поиск в массиве, чтобы найти, какая кнопка вам нужна. И, к моему удовольствию, тест прошел, но это глупый тест, потому что у кнопок есть собственный лог c, поэтому я должен разделить их на отдельные тесты как таковые:

it('increases and decreases button and displays accurate value', () => {
    const component = render(<App/>)
    const buttons = component.getAllByRole('button')

    fireEvent.click(buttons[0])

    expect(component.findByText('1')).toBeTruthy()
})

При необходимости подумайте о том, чтобы обернуть сторонний компонент в div, предоставить data-testid для этих данных, а затем получить доступ к первому, родственному, последнему дочерним узлам, которые являются дочерними для этого div. Я часто использовал это, чтобы перейти к тому месту, где находится сторонний компонентный узел в dom:

<div data-testid="test">
    <SomeComponent onChange={()=> {}}/>
</div>

Поскольку некоторые запросы библиотеки тестирования реакции возвращают dom-узел, мы можем найдите этот компонент с помощью:

const findBootstrapComp = component.getByTestId('test').firstChild

Чего нам, вероятно, следует избегать в максимально возможной степени, но, возможно, ваш случай допустим, учитывая, к чему можно получить доступ с предоставленными запросами, вы можете запросить узел контейнера вручную с помощью некоторого атрибута:

const { container } = render()
const button = container.querySelector('button')

Короче говоря, библиотека тестирования React предоставляет множество инструментов для поиска того, что вам нужно. Если этот сторонний компонент выполняет рендеринг, то, вероятно, для этого элемента есть атрибуты, которые вы можете запросить. Вышесказанное только из личного опыта, каждый проект индивидуален. Можно даже подумать о том, чтобы извлечь эти обратные вызовы, изолировать их и затем протестировать logi c, так как вы больше беспокоитесь о logi c по его звукам.

Кроме того, я согласен с вашим мнением по поводу Boostrap тестирует собственные компоненты. На самом деле вы не хотите тестировать сторонний компонент, вы хотите протестировать некоторые функции или logi c, которые вы написали, к которым обращается сторонний компонент. Или, может быть, вы хотите вытащить css этого элемента и подтвердить, что он не переключался в какой-то момент во время разработки. Как бы то ни было, я надеюсь, что сказанное выше поможет в какой-то мере. Во всяком случае, создайте компонент в тестовом файле с использованием сторонних компонентов и используйте api debug (), чтобы посмотреть на элементы, чтобы узнать, что у них есть, что вы можете запросить.

полезные ссылки:

Шпаргалка библиотеки тестирования React

Dom Navigation

Интерфейс узла