2011-03-30 24 views
6

in un plugin jQuery che ho creato funzioni di aiuto, come questocome testare le funzioni interne nel plugin jquery?

(function($) { 

    var someHelperFunction = function(s, d) { 
    return s*d; 
    } 
    var someOtherHelperFunction = function(s) { 
    return s*2; 
    } 

// here goes the normal plugin code 

})(jQuery); 

ora voglio chiamare someHelperFunction dall'esterno, per essere in grado di unità di test che, è che in qualche modo possibile?

+0

Poiché non è possibile accedere ai metodi dall'esterno, non è possibile. –

risposta

0

gli assistenti hanno un ambito all'interno del plug-in, che è una funzione anonima, e non è possibile accedere alle variabili dichiarate al suo interno.
Se si desidera testarlo, rilasciare la parola chiave var davanti alle funzioni. Questo dichiarerà le funzioni come globali (le assegnerà all'oggetto finestra), dando loro la possibilità di essere visibili dall'ambito della finestra (chiamando someHelperFunction o window.someHelperFunction).
così, per la prova:

(function($) { 
    someHelperFunction = function(s, d) { 
     return s*d; 
    } 
    someOtherHelperFunction = function(s) { 
     return s*2; 
    } 
    // here goes the normal plugin code 
})(jQuery); 

dopo che il test è finito, aggiungere nuovamente la parola chiave var.

Aggiornamento
penso che un approccio migliore sarebbe quello di raggruppare i funzioni testabili in un oggetto - e costruire un'API. Poi, sullo stesso principio, si potrebbe fare che api visibile nella portata globale o no:

(function($, global) { 
    someHelperFunction = function(s, d) { 
     return s*d; 
    } 
    someOtherHelperFunction = function(s) { 
     return s*2; 
    } 

    var api = { 
     someHelperFunction: someHelperFunction, 
     someOtherHelperFunction: someOtherHelperFunction 
    }; 

    // decide whether you want to expose your api or not 
    if(makeGlobal) { 
     global.api = api; 
    } 
})(jQuery, this); 
+4

Divertiti con questo. –

+3

Non utilizzare le variabili globali solo per testare le tue funzioni private. Questa non è una buona risposta perché sostiene le cattive pratiche. – drublic

2

Per this related question, direi solo testare l'interfaccia esterna.

Ma se è necessario testare questi metodi separatamente, è necessario testare "copie" di essi al di fuori del contesto della loro distribuzione come metodi interni. In altre parole, crea un oggetto in cui non sono inaccessibili al codice client e quindi esegui il cobble di quelle versioni insieme allo script esterno in un pre-processo. Sembra un sacco di lavoro, ma hey, questo è il punto di nascondere i metodi, giusto? (Per renderli irraggiungibile.)

-3

un'occhiata a qunit, una prova di unità JavaScript lib

+1

Non si tratta di test in generale. Si tratta di testare i metodi locali. –

+0

oops, mi dispiace .. ha parlato troppo velocemente. nota a sè: leggi attentamente prima di digitare – cander

1

Se le funzioni interne necessitano di test che è un buon indicatore che dovrebbero forse essere in un modulo separato da qualche parte e iniettato come dipendenze e utilizzate all'interno dell'implementazione dell'interfaccia pubblica degli oggetti. Questo è il modo più "testabile" per farlo.

var myActualImplementationTestTheHellOutOfMe = function(s, d) { 

    return s*d; 

} 

(function($, helper) { 

    var someHelperFunction = function(s, d) { 
    return helper(s, d); 
    } 
    var someOtherHelperFunction = function(s) { 
    return s*2; 
    } 

// here goes the normal plugin code 

})(jQuery, myActualImplementationTestTheHellOutOfMe); 
1

Si consiglia inoltre di considerare i doctest JavaScript. Ci sono due implementazioni di cui sono a conoscenza: Ian Bicking's doctest.js e il mio doctest.

+0

Sto cercando di appesantire i pro e i contro di ogni libreria, ma sembrano abbastanza simili. Come autore di doctest, potresti fare una breve interruzione? Il mio caso d'uso è di aggiungere test unitari a [white-space] (https://github.com/dotnetCarpenter/white-space/issues/6) che non ha una API pubblica e ha bisogno di testare fixture e documenti HTML .readyState. – dotnetCarpenter

+0

Innanzitutto, i doctest consentono di verificare gli esempi di utilizzo, assicurando che rimangano aggiornati. I doct testano davvero la * documentazione *, non il codice. In secondo luogo, i doctest funzionano bene per [funzioni pure] (http: // en.wikipedia.org/wiki/Pure_function), ma non per il codice basato su callback. Suggerisco di utilizzare un framework di test dedicato. – davidchambers

+0

Quello che mi piace davvero di doctest è che non devo creare artificialmente un'API pubblica solo per i test. Per quanto ho capito, posso scrivere la documentazione di metodo/funzione all'interno delle chiusure e permetterò comunque l'accesso per i test delle unità. Immagino che sia la limitazione delle funzioni pure che è un rompicapo per me, dal momento che quello che sto veramente testando è il browser comportamento. – dotnetCarpenter

Problemi correlati