Как выполнить модульное тестирование неэкспортированных функций?

Question

В Javascript es6-модуле может быть много маленьких, простых в тестировании функций, которые следует тестировать, но не экспортировать. Как проверить функции в модуле без их экспорта? (без использования rewire )

Answer 1

Хотел бы я иметь лучший ответ для тебя, Джордан. In В прошлом у меня был очень похожий вопрос в контексте JS и C # ...

Ответ, не отвечаю

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

Если вы практикуете TDD, тогда объяснение Марка Симана должно быть уместным (PluralSight) и, надеюсь, прояснит, почему можно выставлять вещи.

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

Просто опция

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

Если это две разные библиотеки, вы можете на очень хорошем уровне контролировать то, что раскрывается и как оно проверяется. Библиотека A будет зависеть от B без утечки каких-либо подробностей B. И A, и B могут тестироваться независимо.

Это потребует другой организации кода, конечно, но это будет работать. Такие инструменты, как Lerna, упрощают многопакетные репозитории для кода JavaScript.

примечание

Я не согласен с @ AlexSzabó, если честно. Тестирование неэкспортированной функции путем тестирования функций, которые ее используют, на самом деле не является модульным тестированием.

Answer 2

Вот возможные варианты, которые я придумала до сих пор, но я ищу лучшие предложения.

Экспорт констант "тестируемых"

function shouldntBeExported(){
    // Does stuff that needs to be tested
}
export function exported(){
    // Does stuff
    return shouldntBeExported();
}
export const testables = {
    shouldntBeExported:shouldntBeExported
}

Идея заключается в том, что я могу получить доступ к shouldntBeExported с помощью import {testables} from 'package'; И он сохраняет контекст подсказки для других разработчиков в моей команде, что его не следует использовать вне пакета, кроме как для тестирования.

Сделайте «shouldntBeExported ()» свойством «exported ()»

Это выглядит очень неправильно, но имеет некоторые уникальные преимущества, особенно если функция должна вызываться только внутри одной «экспортированной» функции, а не в каких-либо других функциях этого пакета. (Конечно, это не невозможно назвать его от других, но это делает более очевидным, где оно принадлежит).

export function exported(){
    // Does stuff
    return exported.shouldntBeExported();
}
exported.shouldntBeExported = function shouldntBeExported(){
    // Does stuff that needs to be tested
}