Как я могу использовать внешнюю библиотеку в своих тестах jest

#javascript #node.js #unit-testing #d3.js #jestjs

#javascript #node.js #модульное тестирование #d3.js #jestjs

Вопрос:

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

 const loadD3 = function(callback) {
  if (window.d3) {
    if (callback) callback(window.d3);
  } else {
    const script = document.createElement('script');
    script.onload = () => {
      if (callback) callback(window.d3);
    };
    script.onerror = () => {
      if (callback) callback();
    };
    document.body.appendChild(script);
    script.src = 'https://cdnjs.cloudflare.com/ajax/libs/d3/4.2.2/d3.min.js';
  }
};

export default loadD3;

 

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

Очевидно, я могу издеваться над всей библиотекой рисования D3, но это огромная задача и кажется совершенно ненужной. Я также хочу проверить, что svg-файл для рисования собран правильно, для чего на самом деле требуется библиотека D3.

Я чувствую, что должен быть способ заставить node загружать и выполнять скрипт D3 перед запуском модульного теста, но я искал и читал уже пару часов и не нашел ничего, что помогло бы.

Итак, мой вопрос: могу ли я написать версию loadD3 , которая немедленно загрузит и выполнит библиотеку D3, чтобы я мог писать модульные тесты, которые проверяют, что на страницу были добавлены правильные элементы рисования?

Комментарии:

1. Я бы установил d3 как зависимость от разработчика и просто импортировал его в ваш файл Jest, как и любой другой плагин. Она не будет включена в ваш обычный пакет, но будет добавлена в пакет тестирования с помощью Jest.

2. Очевидно, я могу издеваться над всей библиотекой рисования D3, но это огромная задача и кажется совершенно ненужной — ну, это необходимо, и вы должны. Jest fake DOM не охватывает сложные случаи и не соответствует ожиданиям от DOM-ориентированных библиотек, таких как D3. Не говоря уже о том, что любая сторонняя библиотека должна быть высмеяна в модульных тестах, если в ней слишком много движущихся частей, что приводит к ошибочным тестам.

3. Спасибо за ваш вклад. Я думаю, что попробую использовать путь зависимости от разработчика.

4. Было бы еще лучше, если бы вы представили d3.js как обычная зависимость также в вашем производственном коде, а не только в ваших модульных тестах. Поэтому установите ее как обычную зависимость и избавьтесь от тега script с помощью жестко закодированного d3.js url-адрес.