Я використовую mocha для тестування програми, написаної для node.js

Цікаво, чи можна одиниці тестових функцій, які не були експортовані в модуль.

Приклад:

У мене дуже багато функцій, визначених у цьому режимі foobar.js

function private_foobar1(){
    ...
}

function private_foobar2(){
    ...
}

і кілька функцій, експортованих як загальнодоступні:

exports.public_foobar3 = function(){
    ...
}

Тест структурований таким чином:

describe("private_foobar1", function() {
    it("should do stuff", function(done) {
        var stuff = foobar.private_foobar1(filter);
        should(stuff).be.ok;
        should(stuff).....

Очевидно, це не працює, оскільки private_foobar1не експортується.

Який правильний спосіб приватного тестування приватних методів? Чи є в моккі деякі вбудовані методи для цього?

Якщо функція не експортується модулем, вона не може бути викликана тестовим кодом поза модулем. Це пов’язано з тим, як працює JavaScript, і Mocha сам по собі не може цього обійти.

У кількох випадках, коли я визначив, що тестування приватної функції - це правильна річ, я зробив встановлення змінної середовища, яку мій модуль перевіряє, щоб визначити, працює він у тестовій установці чи ні. Якщо він працює в тестовій установці, він експортує додаткові функції, які потім можу викликати під час тестування.

Слово "навколишнє середовище" тут вживається вільно. Це може означати перевірку process.envабо щось інше, що може повідомити модуль "Ви зараз тестуєтесь". Випадки, коли мені довелося це зробити, були в середовищі RequireJS, і я використовував module.configдля цього.

Перевірте модуль перемотування . Це дозволяє отримувати (та маніпулювати) приватними змінними та функціями в межах модуля.

Тож у вашому випадку використання буде щось на зразок:

var rewire = require('rewire'),
    foobar = rewire('./foobar'); // Bring your module in with rewire

describe("private_foobar1", function() {

    // Use the special '__get__' accessor to get your private function.
    var private_foobar1 = foobar.__get__('private_foobar1');

    it("should do stuff", function(done) {
        var stuff = private_foobar1(filter);
        should(stuff).be.ok;
        should(stuff).....

Ось справді хороший робочий процес для перевірки ваших приватних методів, пояснений Філіпом Уолтоном, інженером Google у своєму блозі.

Принцип

• Запишіть свій код зазвичай
• Прив’яжіть ваші приватні методи до об'єкта в окремому кодовому блоці, позначте його, _наприклад
• Обведіть цей блок коду коментарями початку та кінця

Потім використовуйте завдання збірки або власну систему збирання (для прикладу grunt-strip-коду), щоб зняти цей блок для виробничих побудов.

Ваші тестові версії мають доступ до ваших приватних програм, а ваші виробничі версії не мають.

Знімок

Напишіть свій код таким чином:

var myModule = (function() {

  function foo() {
    // private function `foo` inside closure
    return "foo"
  }

  var api = {
    bar: function() {
      // public function `bar` returned from closure
      return "bar"
    }
  }

  /* test-code */
  api._foo = foo
  /* end-test-code */

  return api
}())

І ваші такі бурхливі завдання

grunt.registerTask("test", [
  "concat",
  "jshint",
  "jasmine"
])
grunt.registerTask("deploy", [
  "concat",
  "strip-code",
  "jshint",
  "uglify"
])

Більш глибокий

У наступній статті він пояснює "чому" "тестування приватних методів"

Якщо ви хочете, щоб це було просто, просто експортуйте і приватних членів, але чітко відокремлених від загальнодоступного API з певним домовленістю, наприклад, приставку до них _або вкладіть під один приватний об'єкт.

var privateWorker = function() {
    return 1
}

var doSomething = function() {
    return privateWorker()
}

module.exports = {
    doSomething: doSomething,
    _privateWorker: privateWorker
}

Я зробив для цього пакет npm, який вам може бути корисним: вимагаю-з

В основному ви відкриваєте непублічні методи:

module.testExports = {
    private_foobar1: private_foobar1,
    private_foobar2: private_foobar2,
    ...
}

Примітка: testExports може бути будь-яке дійсне ім'я, яке ви хочете, крім exportsзвичайно.

І з іншого модуля:

var requireFrom = require('require-from');
var private_foobar1 = requireFrom('testExports', './path-to-module').private_foobar1;

Я додав додаткову функцію, яку я називаю Internal () і повертаю звідти всі приватні функції. Ця функція Internal () потім експортується. Приклад:

function Internal () {
  return { Private_Function1, Private_Function2, Private_Function2}
}

// Exports --------------------------
module.exports = { PublicFunction1, PublicFunction2, Internal }

Ви можете викликати внутрішні функції так:

let test = require('.....')
test.Internal().Private_Function1()

Найкраще мені подобається це рішення, оскільки:

• завжди експортується лише одна функція Internal () . Ця функція Internal () завжди використовується для тестування приватних функцій.
• Це легко здійснити
• Низький вплив на виробничий код (лише одна додаткова функція)

Я прослідкував за відповіддю @barwin і перевірив, як можна зробити тести одиниць за допомогою модуля перемотування . Я можу підтвердити, що це рішення просто працює.

Модуль повинен бути необхідний у двох частинах - публічній та приватній. Для публічних функцій це можна зробити стандартним способом:

const { public_foobar3 } = require('./foobar');

Для приватного використання:

const privateFoobar = require('rewire')('./foobar');
const private_foobar1 = privateFoobar .__get__('private_foobar1');
const private_foobar2 = privateFoobar .__get__('private_foobar2');

Для того, щоб дізнатися більше про тему, я створив робочий приклад з повним модульним тестуванням, тестування включає приватну та публічну сферу.

Для отримання додаткової інформації я рекомендую вам переглянути статтю ( https://medium.com/@macsikora/how-to-test-private-functions-of-es6-module-fb8c1345b25f ), яка повністю описує тему, включаючи зразки коду.

Я знаю, що це не обов'язково відповідь, яку ви шукаєте, але те, що я знайшов, це те, що більшість часу, якщо приватна функція варта тестувати, варто бути у власному файлі.

Наприклад, замість того, щоб приватні методи були в тому ж файлі, що і загальнодоступні, як цей ...

src / thing / PublicInterface.js

function helper1 (x) {
    return 2 * x;
}

function helper2 (x) {
    return 3 * x;
}

export function publicMethod1(x) {
    return helper1(x);
}

export function publicMethod2(x) {
    return helper1(x) + helper2(x);
}

... Ви розділите його так:

src / thing / PublicInterface.js

import {helper1} from './internal/helper1.js';
import {helper2} from './internal/helper2.js';

export function publicMethod1(x) {
    return helper1(x);
}

export function publicMethod2(x) {
    return helper1(x) + helper2(x);
}

src / річ / внутрішній / helper1.js

export function helper1 (x) {
    return 2 * x;
}

src / річ / внутрішній / helper2.js

export function helper2 (x) {
    return 3 * x;
}

Таким чином, ви можете легко протестувати helper1і helper2як є, не користуючись Rewire та іншими "магіями" (які, як я виявив, мають свої больові точки під час налагодження або коли ви намагаєтесь зробити свій рух до TypeScript, не кажучи вже про бідніші зрозумілість для нових колег). А знаходження в підпапці, що називається internal, або щось подібне, допоможе уникнути випадкового використання їх у ненавмисних місцях.

PS: Ще одна поширена проблема з «приватними» методів є те , що якщо ви хочете перевірити publicMethod1і publicMethod2і знущатися хелперів, знову ж , вам зазвичай потрібно що - щось на зразок Rewire , щоб зробити це. Однак якщо вони знаходяться в окремих файлах, ви можете використовувати Proxyquire для цього, який, на відміну від Rewire, не потребує змін у вашому процесі збирання, простий для читання та налагодження, і добре працює навіть з TypeScript.

Щоб зробити приватні методи доступними для тестування, я роблю це:

const _myPrivateMethod: () => {};

const methods = {
    myPublicMethod1: () => {},
    myPublicMethod2: () => {},
}

if (process.env.NODE_ENV === 'test') {
    methods._myPrivateMethod = _myPrivateMethod;
}

module.exports = methods;