2015-07-16 10 views
7

Non so come definirei questa 'chiamata statica a un router koa'? Questo sembra il giusto testo qui per quello che sto cercando di realizzare se ne parlassi tecnicamente?Come effettuare una chiamata all'istanza dell'app Koa.js per i test delle unità

In ogni caso, sto usando koa-router e sto test delle unità di codifica (non test di integrazione). Quindi non voglio invocare .listen() sulla mia app koa per questo motivo ... creerebbe un server http che ora rende il mio test un test di integrazione.

Invece nel mio test, desidero semplicemente effettuare una chiamata diretta all'istanza dell'oggetto dell'app e chiamare una route e non essere in grado di restituire alcun risultato e controllare che non abbia restituito alcun risultato nella risposta.

Come puoi farlo? Non riesco a trovare un esempio e ho provato tutti i tipi di tentativi di pseudo codice di nuovo l'oggetto app koa.

+0

test contro l'applicazione stessa è un test di integrazione. Vuoi testare l'app stessa (integrazione) o il singolo middleware (test unitari)? –

+0

NO. Sto testando l'interfaccia (contratto) della mia API. Sto esponendo gli endpoint RESTful attraverso Koa. Ciò significa che ho TDD quegli endpoint e quindi il mio TDD che è NON-Integration..sono i test unitari non dovrebbero essere testati su app.Listen().Sto testando mestamente il vero CODICE, il SUT che no non sto testando la struttura di Koa. Si utilizza un framework ma si verifica la logica del dominio o qualsiasi altra cosa. La mia logica di dominio include i percorsi. Perché se uno sviluppatore rompe un percorso, ha appena rotto un test BDD e ha rotto un requisito aziendale. È così che sviluppo il codice. – PositiveGuy

+1

Qui la terminologia viene mescolata. Se stai testando i tuoi percorsi, cioè testando 'GET /', allora devi necessariamente testare quella parte della tua domanda nel suo complesso - il che lo rende un test di integrazione. Se stai testando singole funzioni (che non sei), sei un test unitario. Non vuoi testare il livello che collega la tua applicazione con koa (che dovrebbe essere molto sottile, btw), vuoi solo testare l'integrazione di quel bit. –

risposta

4

Se si desidera testare la funzione su cui il router koa si dirige, eseguire semplicemente un test di unità su tale funzione e lasciare il routing fuori da esso.

A me sembra che tu abbia un file come app.js e contenga tutto il tuo codice. Quello che puoi fare è creare un file router.js per mettere i binari di percorso e un file services.js dove puoi mettere la tua logica applicativa.

Così, per esempio app.js potrebbe essere simile:

var koa = require("koa"); 
var app = module.exports = koa(); 
var router = require('./router.js'); 

app.use(router.unsecured.middleware()); 

app.listen(3000); 

E router.js potrebbe essere simile:

var router = require("koa-router"); 
var service = require("./services.js"); 

var unsecured = module.exports.unsecured = new router(); 

unsecured.post('/account/signin', service.signinUser); 
unsecured.post('/account/register', service.registerUser); 

E services.js potrebbe essere simile:

module.exports.signinUser = function*(signinDetails) { 
    // contains your application signin logic 
}; 

module.exports.registerUser = function*(registerDetails) { 
    // contains your application register logic 
}; 

Quindi in questo modo è possibile testare individualmente services.js. Non vedo alcun valore nel testare individualmente router.js poiché è così banale. Come @Dan Pantry mostra che puoi testare il routing come parte di un test di integrazione usando supertest.

Edit:

Quindi questo è un po 'prova sperimentale stavo giocando intorno con per verificare che il percorso sia corretto. Sto usando mocha come test runner e l'esempio di codice che ho postato nel mio codice originale.

// standard library 
var assert = require("assert"); 

// in app objects 
var router = require('./router.js'); 
var service = require('./service.js'); 

describe("routing tests", function() { 

    it("test register routing, POST", function*(done) { 
    // arrange 
    var unsecured = router.unsecured; 
    var path = '/account/register'; 
    var httpMethod = 'POST'; 
    var expected = service.register.toString(); 
    var actual; 

    // act 
    for (var i = 0; i < unsecured.stack.length; i++) 
    { 
     var pathMatch = unsecured.stack[i].path === path; 
     var methodMatch = unsecured.stack[i].methods.indexOf(httpMethod) >= 0; 

     if (pathMatch && methodMatch) 
     { 
     actual = unsecured.stack[i].middleware.toString(); 
     break; 
     } 
    } 

    // assert 
    try { 
     assert.equal(expected, actual); 
     done(); 
    } catch(err) { 
     done(err); 
    } 
    });  
}); 

C'è probabilmente un modo più ordinato di fare questo (e un modo più modulare per testare percorsi multipli), ma come ho detto questo è solo un esempio di base per verificare l'instradamento sta chiamando il servizio corretto. Quello che sto facendo è scavare nell'oggetto koa-router per verificare quale percorso è legato a quale codice di servizio dipende dal metodo HTTP (ad esempio POST, GET, ecc.).

Se avete il vostro routing e i vostri servizi in moduli questo test evita completamente di gestire l'app koa principale. Sebbene tecnicamente questo test si estenda su più unità (il routing e il codice di servizio), sarebbe tecnicamente un test di integrazione, ma significa che non ti avvicini allo app.listen() che è ciò che non volevi chiamare nei test.

+0

sì questo è come ho già segregato ... ma hai la tua app.listen in app.js quindi è un'enorme differenza, roba buona. – PositiveGuy

+0

il motivo per testare il router è perché alcuni programmatori stupidi potrebbero farlo. Potrebbero rimuovere un percorso, potrebbero pasticciare con il js e finiremo con un router nullo, ogni sorta di cose quindi penso che testare quell'unità sia importante. – PositiveGuy

+0

Controlla la mia modifica per un potenziale approccio per evitare ciò che ti preoccupa ma anche per evitare l'approccio supertest. –