Mocking Postgres per i test unitari con Sinon.js in Node.js

Question

Ho problemi a girare la testa come posso usare sinon per deridere una chiamata a postgres richiesta dal modulo che sto testando, o se è addirittura possibile.

Non sto provando a testare il modulo postgres stesso, solo il mio oggetto per garantire che funzioni come previsto e che stia chiamando ciò che dovrebbe chiamare in questa istanza.

Immagino che il problema sia la configurazione richiesta del nodo, in quanto il mio modulo richiede il modulo postgres per accedere al database, ma qui non voglio eseguire un test di integrazione Voglio solo assicurarmi che il mio codice sia lavorando in isolamento, e non mi interessa davvero cosa stia facendo il database, lo lascerò ai miei test di integrazione.

Ho visto alcune persone che impostano le loro funzioni per avere un parametro opzionale per inviare il falso/stub/falso alla funzione, testarne la sua esistenza e se è lì, utilizzarlo sul modulo richiesto, ma sembra un odore per me (sono nuovo al nodo quindi forse questo non lo è).

Preferirei deridere questo, piuttosto che provare a dirottare il bisogno se ciò è possibile.

po 'di codice (si prega di notare che questo non è il vero codice come sto facendo funzionare con TDD e la funzione non fa nulla in realtà, i nomi delle funzioni sono reali)

TEST SETUP

describe('#execute', function() { 
it('should return data rows when executing a select', function(){ 
//Not sure what to do here 
}); 
}); 

CAMPIONE FUNZIONE

PostgresqlProvider.prototype.execute = function (query, cb) { 
var self = this; 

if (self.connection === "") 
    cb(new Error('Connection can not be empty, set Connection using Init function')); 

if (query === null) 
    cb(new Error('Invalid Query Object - Query Object is Null')) 

if (!query.buildCommand) 
    cb(new Error("Invalid Query Object")); 

//Valid connection and query 
}; 

Potrebbe sembrare un po 'divertente avvolgere il modulo postgres in questo modo, ma ci sono alcuni design in quanto questa app avrà diversi "provider" e voglio esporre la stessa API per tutti loro in modo da poterli usare in modo intercambiabile.

UPDATE

ho deciso che il mio test era troppo complicato, mentre stavo cercando di vedere se la chiamata di connessione era stata fatta e quindi la restituzione dei dati, che sapeva a me, così ho messo a nudo indietro e mettere in due prove:

il test di simulazione

it('should call pg.connect when a valid Query object is parsed', function(){ 
     var mockPg = sinon.mock(pg); 
     mockPg.expects('connect').once;    

     Provider.init('ConnectionString'); 
     Provider.execute(stubQueryWithBuildFunc, null, mockPg); 

     mockPg.verify(); 
    }); 

Questo funziona (credo) come, senza il codice connettore Postgres non riesce, con esso passe s (Boom :))

Il problema ora è con il secondo metodo, che sto per usare uno stub (forse una spia) che sta passando al 100% quando dovrebbe fallire, quindi lo raccoglierò al mattino .

Update 2

io non sono soddisfatto al 100% con il test, soprattutto perché non sono dirottamento il metodo client.query che è quella che colpisce il database, ma semplicemente il mio metodo Execute e costringendolo lungo un percorso, ma mi permette di vedere il risultato e affermare contro di esso per testare il comportamento, ma sarebbe aperto a eventuali miglioramenti suggeriti.

Sto usando una spia per catturare il metodo e restituisco null e un oggetto faux con contiene righe, come se il metodo passasse indietro, questo test cambierà man mano che aggiungo altro comportamento di query ma mi supera il mio ostacolo.

it('should return data rows when a valid Query object is parsed', function(){ 

     var fauxRows = [ 
      {'id': 1000, 'name':'Some Company A'}, 
      {'id': 1001, 'name':'Some Company B'} 
     ]; 

     var stubPg = sinon.stub(Provider, 'execute').callsArgWith(1, null, fauxRows); 

     Provider.init('ConnectionString'); 
     Provider.execute(stubQueryWithBuildFunc, function(err, rows){ 
      rows.should.have.length(2); 
     }, stubPg); 

     stubPg.called.should.equal.true; 
     stubPg.restore(); 
    }); 

Answer 1

Usa pg-piscina: https://www.npmjs.com/package/pg-pool

E 'in procinto di essere aggiunto alla pg comunque e presumibilmente fa (beffardo) unit test facile ... da BrianC (https://github.com/brianc/node-postgres/issues/1056#issuecomment-227325045):

Checkout https://github.com/brianc/node-pg-pool - molto presto sarà l'implementazione del pool in node-postgres e non si affida ai singleton, il che rende molto più semplice il mocking. Speriamo che questo aiuti!

Answer 2

Sostituisco molto esplicitamente le mie dipendenze. Probabilmente non è la soluzione migliore, ma tutte le altre soluzioni che ho visto non erano neanche così grandiose.

inject: function (_mock) { 
    if (_mock) { real = _mock; } 
} 

Aggiungere questo codice al modulo in prova. Nei miei test chiamo il metodo di iniezione e sostituisco l'oggetto reale. Il motivo per cui non mi piace del 100% è che devi aggiungere codice extra solo per i test.

L'altra soluzione è leggere il file del modulo come una stringa e utilizzare vm per caricare manualmente il file. Quando ho studiato questo ho trovato un po 'troppo complesso, quindi sono andato usando solo la funzione inject. Probabilmente vale la pena investigare su questo approccio. Puoi trovare ulteriori informazioni here.