Rivelazione del modello del modulo - Test dell'unità con Jasmine

Question

Dopo una breve storia d'amore con il modello del modulo rivelatore, sono arrivato a realizzare un arretramento quando si tratta di moduli di test unitari. Non riesco tuttavia a decidere se è il mio approccio a testare un modulo o se c'è qualche forma di soluzione.

Si consideri il seguente codice:

var myWonderfulModule = (function() { 
    function publicMethodA (condition) { 
    if(condition === 'b') { 
     publicMethodB(); 
    } 
    } 

    function publicMethodB() { 
    // ... 
    } 

    return { 
    methodA : publicMethodA, 
    methodB : publicMethodB 
    } 
}()); 

Se ho voluto mettere alla prova (utilizzando Jasmine) i vari sentieri che attraversano publicMethodA a publicMethodB. Potrei scrivere un piccolo test in questo modo:

it("should make a call to publicMethodB when condition is 'b'", function() { 
    spyOn(myWonderfulModule , 'publicMethodB'); 
    myWonderfulModule.publicMethodA('b'); 
    expect(myWonderfulModule.publicMethodB).toHaveBeenCalled(); 
}); 

Se ho capito bene, c'è una copia della publicMethodB all'interno della chiusura, che non può essere cambiato. Anche se cambio myWonderfulModule.publicMethodB in seguito:

myWonderfulModule.publicMethodB = undefined; 

chiamando myWonderfulModule.publicMethodA sarà ancora eseguire la versione originale di B.

L'esempio di cui sopra è ovviamente semplificata, ma ci sono un sacco di scenari che posso pensare dove sarebbe conveniente per unit test percorsi condizionali attraverso un metodo.

Questa è una limitazione del modulo del modulo rivelatore o semplicemente un uso improprio del test dell'unità? Se no, quali soluzioni sono disponibili per me? Sto considerando di passare a qualcosa come RequireJS o tornare al codice non modulare.

Qualche consiglio apprezzato!

Answer 1

Non puoi testare i metodi interni di una chiusura. E non dovresti nemmeno spiarlo. Pensa al tuo modulo come a una scatola nera. Metti qualcosa dentro e ottieni qualcosa. Tutto quello che dovresti testare è che la cosa che esci dal tuo modulo è quella che ti aspetti.

Spiare i metodi nel modulo non ha molto senso. Pensaci. Lo spii, il test passa. Ora si cambia la funzionalità in modo che crei un bug, il test passa ancora perché la funzione è ancora chiamata ma non si parla mai del bug. Se si verifica solo la cosa che viene fuori non è necessario spiare i metodi interni, perché sono chiamati impliciti quando il risultato del modulo è quello che si aspetta.

Quindi nel tuo caso non c'è nulla che entri e non venga fuori nulla. Questo non ha molto senso ma credo che il tuo modulo interagisca con DOM o effettui una chiamata ajax. Queste sono cose che puoi testare (DOM) o dovresti spiare (ajax).

Si dovrebbe anche familiarizzarsi con Inversion of Control and Dependency Injection. Questi sono schemi che renderanno i tuoi moduli molto più facili da testare.

Answer 2

Se si utilizza la parola chiave "this" quando si chiama publicMethodB() da publicMethodA() funzionerà. Ad esempio:

var myWonderfulModule = (function() { 
    function publicMethodA (condition) { 
     if(condition === 'b') { 
      this.publicMethodB(); 
     } 
    } 

    function publicMethodB() { 
     // ... 
    } 

    return { 
     methodA : publicMethodA, 
     methodB : publicMethodB 
    } 
}());