Estoy usando mocha para probar una aplicación escrita para node.js

Me pregunto si es posible unir las funciones de prueba que no se han exportado en un módulo.

Ejemplo:

Tengo muchas funciones definidas así en foobar.js

function private_foobar1(){
    ...
}

function private_foobar2(){
    ...
}

y algunas funciones exportadas como públicas:

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

El caso de prueba se estructura de la siguiente manera:

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

Obviamente esto no funciona, ya private_foobar1que no se exporta.

¿Cuál es la forma correcta de probar los métodos privados? ¿Tiene mocha algunos métodos incorporados para hacerlo?

Si el módulo no exporta la función, no se puede invocar mediante código de prueba fuera del módulo. Eso se debe a cómo funciona JavaScript, y Mocha no puede evitar esto por sí solo.

En los pocos casos en que determiné que probar una función privada es lo correcto, lo que hice fue establecer alguna variable de entorno que mi módulo verifica para determinar si se está ejecutando en una configuración de prueba o no. Si se ejecuta en la configuración de prueba, exporta funciones adicionales a las que puedo llamar durante la prueba.

La palabra "medio ambiente" se usa libremente aquí. Puede significar una comprobación process.envo algo más que pueda comunicarse con el módulo "estás siendo probado ahora". Las instancias donde tuve que hacer esto fueron en un entorno RequireJS, y lo he usado module.configpara este propósito.

Echa un vistazo al módulo de recableado . Le permite obtener (y manipular) variables y funciones privadas dentro de un módulo.

Entonces, en su caso, el uso sería algo como:

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).....

Aquí hay un flujo de trabajo realmente bueno para probar sus métodos privados explicado por Philip Walton, un ingeniero de Google en su blog.

Principio

• Escribe tu código normalmente
• Unen sus métodos particulares al objeto en un bloque de código independiente, marcan su por una _, por ejemplo,
• Rodea ese bloque de código con comentarios iniciales y finales

Luego use una tarea de compilación o su propio sistema de compilación (por ejemplo, grunt-strip-code) para eliminar este bloque para compilaciones de producción.

Sus compilaciones de prueba tienen acceso a su API privada, y sus compilaciones de producción no.

Retazo

Escribe tu código como este:

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
}())

Y tus gruñidos como ese

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

Mas profundo

En un artículo posterior , explica el "por qué" de "probar métodos privados"

Si prefiere que sea simple, simplemente exporte los miembros privados también, pero claramente separados de la API pública con alguna convención, por ejemplo, prefije con _o anidelos bajo un solo objeto privado .

var privateWorker = function() {
    return 1
}

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

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

Hice un paquete npm para este propósito que puede resultarle útil: require-from

Básicamente expones métodos no públicos mediante:

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

nota: testExports puede ser cualquier nombre válido que desee, excepto, exportspor supuesto.

Y de otro módulo:

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

He agregado una función adicional que denomino Internal () y devuelvo todas las funciones privadas desde allí. Esta función interna () se exporta. Ejemplo:

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

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

Puede llamar a las funciones internas de esta manera:

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

Esta solución me gusta más porque:

• solo se exporta una función interna () . Esta función interna () siempre se usa para probar funciones privadas.
• Es simple de implementar
• Bajo impacto en el código de producción (solo una función adicional)

Seguí @barwin respuesta y comprobado cómo las pruebas unitarias se pueden hacer con recableado módulo. Puedo confirmar que esta solución simplemente funciona.

El módulo debe requerirse en dos partes: una pública y una privada. Para funciones públicas, puede hacerlo de manera estándar:

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

Para ámbito privado:

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

Para saber más sobre el tema, creé un ejemplo de trabajo con pruebas de módulo completo, las pruebas incluyen alcance privado y público.

Para obtener más información, le recomiendo que consulte el artículo ( https://medium.com/@macsikora/how-to-test-private-functions-of-es6-module-fb8c1345b25f ) que describe completamente el tema, incluye ejemplos de código.

Sé que esta no es necesariamente la respuesta que está buscando, pero lo que he encontrado es que la mayoría de las veces si vale la pena probar una función privada, vale la pena estar en su propio archivo.

Por ejemplo, en lugar de tener métodos privados en el mismo archivo que los públicos, como este ...

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);
}

... lo dividiste así:

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 / thing / internal / helper1.js

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

src / thing / internal / helper2.js

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

De esa manera, puede probar fácilmente helper1y helper2tal cual, sin usar Rewire y otras "magias" (que, según he descubierto, tienen sus propios puntos de dolor durante la depuración, o cuando intenta avanzar hacia TypeScript, sin mencionar que son más pobres) comprensibilidad para nuevos colegas). Y estar en una subcarpeta llamada internal, o algo así, ayudará a evitar su uso accidental en lugares no deseados.

PD: Otro problema común con los métodos de "privado" es que si quieres prueba publicMethod1y publicMethod2y burlas de los ayudantes, de nuevo, que normalmente necesita algo así como Recablear de hacer eso. Sin embargo, si están en archivos separados, puede usar Proxyquire para hacerlo, que, a diferencia de Rewire, no necesita ningún cambio en su proceso de compilación, es fácil de leer y depurar, y funciona bien incluso con TypeScript.

Para hacer que los métodos privados estén disponibles para las pruebas, hago esto:

const _myPrivateMethod: () => {};

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

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

module.exports = methods;