Как написать qunit-тест к приватным функциям, скрытым за ширмой?

Question

[Алексей Николаев]

Доброй ночи всем.
Изучаю qunit. С самого начала интересовал один вопрос: какова best practice тестирования систем, в которых 90% кода скрыто от доступа рядового пользователя (например, плагин)? Стандартная схема ведь такова:
- подключаем qunit.js \ css
- подключаем scripts.js, с плагином \ скриптами, которые тестируем
- подключаем сами тесты

При этом не нашел никаких инструментов, чтобы протестировать приватный метод, который недоступен извне - это невозможно тем способом, каким тестируются прочие, публичные функции. И я вижу несколько вариантов для решения проблемы:
- держать 2 версии: дев (с доступными извне методами), и продакшен-сборку
- писать тесты прямо внутри нашего script.js (qunit позволяет запускать тесты по цепочке), на мой взгляд - решение грязное, но лучше, чем держать специальную версию с доступными извне методами

Поверхностный поиск на тему tdd никаких внятных результатов на эту тему не дал, да и освещаются там несколько иные вопросы.

Буду благодарен за наводки на нужную колею, заранее спасибо.

P.S. набрел на статью о Jasmine, которая подтверждает второй вариант. Но не оставляет ли этот подход непокрытыми тестами некоторые из функций?

Answer 1

[Константин Китманов]

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

На практике, если хочется покрыть тестами какую-то библиотеку, можно поступить так: создаем index.js и отдельные файлики по вкусу, все в формате CommonJS модулей. index.js require'ит все файлики и делает module.exports тех вещей, которые должны быть публичными. Тесты require'ят файлики по отдельности. Таким образом, библиотека как целое предоставляет наружу только публичный интерфейс, но внутренняя механика покрыта тестами. По желанию CommonJS заменяются на универсальные модули.

Answer 2

[Максим Гаврилов]

Приватные функции не тестируются. Но кто же запретит если очень хочется :). В таком случае можно создать механизм доступа к приватным функциям и тестировать.

Answer 3

[Алексей Огоньков]

А чем не нравится сборка отдельно для прода и тестирования?

Comments

[Алексей Николаев]

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

[Алексей Огоньков]

Алексей Николаев: ну я не знаю насколько экспорт приватных переменных можно считать "отдельной версией"

define(function() {
  function somethingPrivate() {}

  function MyClass {}

  var exports = {
    Create: MyClass
  };


  if (DEBUG) {
    extend(exports, {
      somethingPrivate: somethingPrivate
    });
  }

  return exports;
});