2015-07-16 11 views
7

Nie wiem, jak nazwałbym to może "statyczne połączenie z routerem koa"? Czy to brzmi jak właściwe sformułowanie tego, co tak naprawdę staram się osiągnąć, gdybyś miał o tym technicznie mówić?Jak nawiązać połączenie z instancją aplikacji Koa.js dla testów jednostkowych

W każdym razie używam koa-router i testuję jednostki kodujące (nie testy integracyjne). Tak więc nie chcę wywoływać .listen() w mojej aplikacji koa z tego powodu ... stworzy to serwer http, który sprawi, że mój test będzie testem integracyjnym.

Zamiast tego w moim teście chcę po prostu wykonać bezpośrednie wywołanie instancji obiektu aplikacji i wywołać trasę, a następnie zwrócić wyniki i sprawdzić, czy nie zwróciłem żadnych wyników w odpowiedzi.

Jak możesz to zrobić? Nie mogę znaleźć przykładu i wypróbowałem wszystkie rodzaje pseudokodowania, które dotyczą obiektu aplikacji koa.

+0

Testowanie samej aplikacji jest testem integracyjnym. Czy chcesz przetestować samą aplikację (integrację) lub indywidualne oprogramowanie pośrednie (testy jednostkowe)? –

+0

NIE. Testuję interfejs (kontrakt) mojego API. Ujawniam RESTful punkty końcowe za pośrednictwem Koa. Oznacza to, że TDD tych punktów końcowych, a więc mój TDD, który jest NON-Integration .. są to testy jednostkowe nie powinny być testowanie przez app.Listen().Próbuję przetestować rzeczywisty KOD, czyli SUT, którego nie testuję ram Koa. Korzystasz z frameworka, ale testujesz logikę domeny lub cokolwiek innego. Moja logika domeny obejmuje trasy. Ponieważ, jeśli programista złamie trasę, po prostu złamał test BDD i złamał wymóg biznesowy. Tak rozwijam kod. – PositiveGuy

+1

Zmieniasz tu terminologię. Jeśli testujesz trasy, tj. Testujesz 'GET /', musisz koniecznie przetestować tę część aplikacji jako całość - co czyni test integracyjny. Jeśli testujesz poszczególne funkcje (których nie masz), testujesz urządzenie. Nie chcesz testować warstwy, która łączy twoją aplikację z koa (która powinna być bardzo cienka, btw), chcesz tylko test integracji, który bit. –

Odpowiedz

4

Jeśli chcesz przetestować funkcję, do której prowadzi router koa, po prostu wykonaj test jednostkowy na tej funkcji i pozostaw z niej routing.

Dla mnie wygląda na to, że masz plik taki jak app.js i zawiera on cały twój kod. Możesz utworzyć plik router.js, aby umieścić wiązania routingu i plik services.js, w którym możesz umieścić logikę aplikacji.

Tak na przykład app.js może wyglądać następująco:

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

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

app.listen(3000); 

I router.js może wyglądać następująco:

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

I services.js może wyglądać następująco:

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

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

W ten sposób można indywidualnie testować plik services.js. Nie widzę żadnej wartości w pojedynczych testach router.js, ponieważ jest to tak trywialne. Jak pokazuje @Dan Pantry, możesz przetestować routing w ramach testu integracji za pomocą supertest.

Edit:

Więc to jest trochę badanie eksperymentalne Grałem około z przetestować że routingu jest poprawna. Używam mocha jako testera i przykład kodu, który zamieściłem w moim oryginalnym kodzie.

// 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); 
    } 
    });  
}); 

Nie ma chyba neater sposób to zrobić (i bardziej modułowy sposób do testowania wielu ścieżek), ale jak już mówiłem jest to tylko prosty przykład, aby sprawdzić ułożenie dzwoni prawidłową obsługę. Co robię, to zagłębianie się w obiekt koa-router, aby sprawdzić, która ścieżka jest powiązana z kodem usługi w zależności od metody HTTP (np. POST, GET, itp.).

Jeśli masz swój routing i swoje usługi w modułach, to test ten całkowicie unika pracy z główną aplikacją Koa. Chociaż technicznie ten test obejmuje wiele jednostek (routing i kod usługi), więc technicznie jest to test integracyjny, ale oznacza to, że nie zbliżasz się do app.listen(), czego nie chcesz wywoływać w testach.

+0

tak to jak już to posegregowałem ... ale masz app.listen w app.js, więc to jest ogromna różnica, dobre rzeczy. – PositiveGuy

+0

powodem testowania routera jest to, że jakiś głupi programista może go zrzucić. Mogliby usunąć trasę, mogliby zadzwonić z js i skończylibyśmy z zerowym routerem, różnymi rzeczami, więc uważam, że testowanie tej jednostki jest ważne. – PositiveGuy

+0

Sprawdź moją edycję pod kątem możliwego podejścia do unikania tego, co cię martwi, ale unikaj również supertestowego podejścia. –

Powiązane problemy