Методы модульного тестирования, объявленные внутри другого метода в Node - PullRequest
Новая
       7

Методы модульного тестирования, объявленные внутри другого метода в Node

0 голосов
/ 21 февраля 2019

у меня есть модуль узла следующего формата 

'use strict’;

/// require dependencies here 

function outerFunc1(a, b, c) {

  function f1() {
    return f2()
  }

  function f2() {
    return 2
  }
  f1();
}
const choose = (type) => {
  let funcToCall
  switch (type) {
    case "func1":
      funcToCall = outerFunc1;
      break;
  }
  return funcToCall;
}

module.exports = (function () {
  return {
    choose
  };
})();

Может кто-нибудь сказать мне, как выполнить модульное тестирование функций f2 и f1 или другими словами, как я могу вызвать то же самое, есть ли способдобиться того же, как с помощью отражения API или любым другим способом с помощью rewire или sinon?

1 Ответ

0 голосов
/ 24 февраля 2019

Все функции f1 и f2 могут быть легко стимулированы косвенно из общедоступных функций API.Следовательно, нет веских оснований для их проверки самостоятельно.Напротив, есть причины, по которым они сами тестируют: всякий раз, когда изменяется реализация outerFunc1, вероятность того, что на f1 или f2 повлияют так, что это нарушит тесты, кажется высокой.

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

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

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

...