Sto usando moka per testare un'unità un'applicazione scritta per node.js

Mi chiedo se sia possibile eseguire funzioni di unit test che non sono state esportate in un modulo.

Esempio:

Ho molte funzioni definite in questo modo in foobar.js

function private_foobar1(){
    ...
}

function private_foobar2(){
    ...
}

e alcune funzioni esportate come pubbliche:

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

Il caso di test è strutturato come segue:

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

Ovviamente questo non funziona, poiché private_foobar1non viene esportato.

Qual è il modo corretto di testare metodi privati? La moka ha alcuni metodi integrati per farlo?

Se la funzione non viene esportata dal modulo, non può essere richiamata dal codice di test esterno al modulo. Ciò è dovuto al modo in cui funziona JavaScript e Mocha non può da sola aggirare questo.

Nei pochi casi in cui ho determinato che testare una funzione privata è la cosa giusta da fare, quello che ho fatto è impostare una variabile d'ambiente che il mio modulo controlla per determinare se è in esecuzione in una configurazione di prova o meno. Se viene eseguito nella configurazione del test, esporta funzioni aggiuntive che posso quindi chiamare durante il test.

La parola "ambiente" è qui usata vagamente. Potrebbe significare il controllo process.envo qualcos'altro che può comunicare al modulo "sei in fase di test ora". I casi in cui ho dovuto farlo erano in un ambiente RequireJS, e ho usato module.configper questo scopo.

Dai un'occhiata al modulo rewire . Ti permette di ottenere (e manipolare) variabili e funzioni private all'interno di un modulo.

Quindi nel tuo caso l'utilizzo sarebbe qualcosa del tipo:

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

Ecco un ottimo flusso di lavoro per testare i tuoi metodi privati spiegati da Philip Walton, un ingegnere di Google sul suo blog.

Principio

• Scrivi il tuo codice normalmente
• Associa i tuoi metodi privati ​​all'oggetto in un blocco di codice separato, contrassegnalo con un _esempio
• Circonda quel blocco di codice dai commenti di inizio e fine

Quindi utilizzare un'attività di compilazione o il proprio sistema di compilazione (ad esempio grunt-strip-code) per rimuovere questo blocco per build di produzione.

Le build di test hanno accesso alle API private e le build di produzione no.

Frammento

Scrivi il tuo codice come questo:

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

E i tuoi compiti grugniti in quel modo

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

Più in profondità

In un articolo successivo , spiega il "perché" del "test di metodi privati"

Se preferisci mantenerlo semplice, esporta anche i membri privati, ma chiaramente separati dall'API pubblica con alcune convenzioni, ad esempio prefissandoli con _o annidali sotto un singolo oggetto privato .

var privateWorker = function() {
    return 1
}

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

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

Ho creato un pacchetto npm con questo scopo che potresti trovare utile: request -from

Fondamentalmente si espongono metodi non pubblici mediante:

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

nota: testExports può essere qualsiasi nome valido che desideri, tranne exportsovviamente.

E da un altro modulo:

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

Ho aggiunto una funzione extra che ho chiamato Internal () e restituisco tutte le funzioni private da lì. Questa funzione interna () viene quindi esportata. Esempio:

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

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

Puoi chiamare le funzioni interne in questo modo:

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

Mi piace di più questa soluzione perché:

• viene sempre esportata solo una funzione Internal () . Questa funzione Internal () viene sempre utilizzata per testare le funzioni private.
• È semplice da implementare
• Basso impatto sul codice di produzione (solo una funzione aggiuntiva)

Ho seguito la risposta di @barwin e verificato come è possibile effettuare test unitari con il modulo rewire . Posso confermare che questa soluzione funziona semplicemente.

Il modulo dovrebbe essere richiesto in due parti: una pubblica e una privata. Per le funzioni pubbliche puoi farlo in modo standard:

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

Per ambito privato:

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

Per saperne di più sull'argomento, ho creato un esempio funzionante con test del modulo completo, il test include ambito privato e pubblico.

Per ulteriori informazioni, ti incoraggio a consultare l'articolo ( https://medium.com/@macsikora/how-to-test-private-functions-of-es6-module-fb8c1345b25f ) che descrive completamente l'argomento, include esempi di codice.

So che questa non è necessariamente la risposta che stai cercando, ma quello che ho trovato è che la maggior parte delle volte se vale la pena testare una funzione privata, vale la pena trovarsi nel suo file.

Ad esempio invece di avere metodi privati ​​nello stesso file di quelli pubblici, come questo ...

src / cosa / 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 hai suddiviso in questo modo:

src / cosa / 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 / cosa / interni / helper1.js

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

src / cosa / interni / helper2.js

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

In questo modo, puoi facilmente testare helper1e così helper2com'è, senza usare Rewire e altre "magie" (che, ho scoperto, hanno i loro punti deboli durante il debug o quando provi a muoverti verso TypeScript, per non parlare dei più poveri comprensibilità per i nuovi colleghi). E il fatto che si trovino in una sottocartella denominata internal, o qualcosa del genere, aiuterà a evitare un uso accidentale di essi in luoghi non previsti.

PS: Un altro problema comune con i metodi "privati" è che se si vuole testare publicMethod1e publicMethod2e deridere l'aiutanti, ancora una volta, che normalmente bisogno di qualcosa come Rewire per farlo. Tuttavia, se si trovano in file separati, è possibile utilizzare Proxyquire per farlo, che, a differenza di Rewire, non ha bisogno di modifiche al processo di compilazione, è facile da leggere e da debug e funziona bene anche con TypeScript.

Per rendere disponibili metodi privati ​​per i test, faccio questo:

const _myPrivateMethod: () => {};

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

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

module.exports = methods;