модульное тестирование, охватывающее случай филиала

Question

Я пытаюсь написать модульный тест для ниже .js, используя mocha

const fs = require('fs')
const defaultValue = 255

const envValue = process.env.Var1Value
const valueToUse = envValue && !isNaN(envValue) ? parseInt(envValue) : defaultValue

module.exports.MyFun = () => {
  //use the value of 'valueToUse'
}

В моем модульном тестировании я пытаюсь охватить случаи для "valueToUse" как из среды, так и из значения по умолчанию.Я пытаюсь понять, как можно охватить оба сценария для модульного тестирования.Если я устанавливаю process.env.Var1Value до загрузки модуля (используя require), он охватывает первый сценарий, но не другой случай, и наоборот, если я не устанавливаю переменную env, он покрывает другой случай, так как модульзагружается только один раз ... как мне провести модульное тестирование, которое охватывает оба сценария?Заранее спасибо!

Answer 1

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

Альтернативный вариант - превратить код запуска в нечто, что может быть повторно выполнено под управлением тестового кода - например, в виде некоторой функции init(), которая вычисляет значения глобальных / статических переменных. Для запуска производственного кода это не оказывает большого влияния на производительность, и в производственном коде функция init() действительно будет вычислена только один раз. За производительность во время исполнения штрафов нет вообще. Однако для модульного тестирования это дает то преимущество, что вы можете звонить init() так часто, как хотите.

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

По общему признанию, все это - компромиссы: Вы также не можете классифицировать переменные как const и т. Д. Однако именно поэтому существует понятие, называемое «дизайн для тестируемости»: поскольку тестируемый код иногда выглядит иначе, чем код, который не был разработан для проверки.