Как один модуль тестирует маршруты с помощью Express?

99

Я изучаю Node.js и играю с Express . Мне очень нравится фреймворк; однако мне сложно понять, как написать тест модуля / интеграции для маршрута.

Возможность модульного тестирования простых модулей проста, и мы уже делали это с помощью Mocha ; однако мои модульные тесты с Express терпят неудачу, поскольку объект ответа, который я передаю, не сохраняет значения.

Тестируемая функция маршрута (routes / index.js):

exports.index = function(req, res){
  res.render('index', { title: 'Express' })
};

Модуль модульного тестирования:

var should = require("should")
    , routes = require("../routes");

var request = {};
var response = {
    viewName: ""
    , data : {}
    , render: function(view, viewData) {
        viewName = view;
        data = viewData;
    }
};

describe("Routing", function(){
    describe("Default Route", function(){
        it("should provide the a title and the index view name", function(){
        routes.index(request, response);
        response.viewName.should.equal("index");
        });

    });
});

Когда я запускаю это, он не дает «Ошибка: обнаружены глобальные утечки: viewName, data».

  1. Где я ошибаюсь, чтобы заставить это работать?

  2. Есть ли лучший способ провести модульное тестирование моего кода на этом уровне?

Обновление 1. Исправлен фрагмент кода, так как я изначально забыл "it ()".

node.js  express 
— Джеймс Эггерс
источник

Ответы:

21

Измените свой объект ответа:

var response = {
    viewName: ""
    , data : {}
    , render: function(view, viewData) {
        this.viewName = view;
        this.data = viewData;
    }
};

И это сработает.

— Линус Тиль
источник
4
Это модульное тестирование обработчика запроса, а не маршрута.
— Джейсон Себринг
43

Как другие рекомендовали в комментариях, похоже, что канонический способ тестирования контроллеров Express - это супертест .

Пример теста может выглядеть так:

describe('GET /users', function(){
  it('respond with json', function(done){
    request(app)
      .get('/users')
      .set('Accept', 'application/json')
      .expect(200)
      .end(function(err, res){
        if (err) return done(err);
        done()
      });
  })
});

Плюс: вы можете протестировать весь свой стек за один раз.

Оборотная сторона: это похоже на интеграционное тестирование и действует так же.

— Рич Аподака
источник
1
Мне это нравится, но есть ли способ утверждать viewName (как в исходном вопросе) - или нам придется утверждать содержание ответа?
— Alex
21
Я согласен с вашей обратной стороной, это не модульное тестирование. Это зависит от интеграции всех ваших модулей для проверки URL-адресов вашего приложения.
— Люк Х,
10
Я думаю, что законно говорить, что «маршрут» действительно есть integration, и, возможно, маршруты тестирования следует оставить на усмотрение интеграционных тестов. Я имею в виду, что функциональность маршрутов, соответствующих их определенным обратным вызовам, предположительно уже протестирована express.js; любая внутренняя логика для получения окончательного результата маршрута в идеале должна быть модульной вне ее, и эти модули должны быть модульно протестированы. Их взаимодействие, т. Е. Маршрут, следует тестировать на интеграцию. Вы бы согласились?
— Aditya MP
1
Это сквозное тестирование. Без сомнений.
— kgpdeveloper 03
25

Я пришел к выводу, что единственный способ действительно модульного тестирования экспресс-приложений - это поддерживать значительное разделение между обработчиками запросов и вашей базовой логикой.

Таким образом, логика вашего приложения должна быть в отдельных модулях, которые можно requireтестировать и тестировать отдельно , и иметь минимальную зависимость от классов Express Request и Response как таковых.

Затем в обработчиках запросов вам нужно вызвать соответствующие методы классов базовой логики.

Я приведу пример, как только закончу реструктуризацию моего текущего приложения!

Я думаю что-то вроде этого? (Не стесняйтесь изложить суть или комментарий, я все еще изучаю это).

редактировать

Вот крошечный пример, встроенный. См. Суть для более подробного примера.

/// usercontroller.js
var UserController = {
   _database: null,
   setDatabase: function(db) { this._database = db; },

   findUserByEmail: function(email, callback) {
       this._database.collection('usercollection').findOne({ email: email }, callback);
   }
};

module.exports = UserController;

/// routes.js

/* GET user by email */
router.get('/:email', function(req, res) {
    var UserController = require('./usercontroller');
    UserController.setDB(databaseHandleFromSomewhere);
    UserController.findUserByEmail(req.params.email, function(err, result) {
        if (err) throw err;
        res.json(result);
    });
});
— Люк Х
источник
3
На мой взгляд, это лучший шаблон для использования. Многие веб-фреймворки на разных языках используют шаблон контроллера, чтобы отделить бизнес-логику от фактических функций формирования HTTP-ответа. Таким образом, вы можете просто протестировать логику, а не весь процесс HTTP-ответа, который разработчики фреймворка должны тестировать самостоятельно. Другие вещи, которые могут быть протестированы в этом шаблоне, - это простое промежуточное программное обеспечение, некоторые функции проверки и другие бизнес-сервисы. Однако тестирование подключения к БД - это совершенно другой тип тестирования,
— OzzyTheGiant
1
Действительно, многие ответы здесь действительно связаны с интеграционным / функциональным тестированием.
— Люк Х
Это правильный ответ. Вам следует сосредоточиться на проверке своей логики, а не на Express.
— esmiralha
19

Самый простой способ проверить HTTP с помощью express - украсть http-помощник TJ.

Я лично использую его помощник

it("should do something", function (done) {
    request(app())
    .get('/session/new')
    .expect('GET', done)
})

Если вы хотите специально протестировать свой объект маршрутов, передайте правильные макеты

describe("Default Route", function(){
    it("should provide the a title and the index view name", function(done){
        routes.index({}, {
            render: function (viewName) {
                viewName.should.equal("index")
                done()
            }
        })
    })
})
— Райнос
источник
5
не могли бы вы исправить ссылку "помощник"?
— Николас Мюррей
16
Похоже, что более современный подход к модульному тестированию HTTP заключается в использовании супертеста от Visionmedia. Также кажется, что http-помощник TJ превратился в супертест.
— Аксели Пален,
2
супертест на github можно найти здесь
— Брэндон
@Raynos, не могли бы вы объяснить, как вы получаете запрос и приложение в своем примере?
— jmcollin92 06
9
К сожалению, это интеграционное тестирование, а не модульное тестирование.
— Люк Х,
8

если модульное тестирование с экспресс-4, обратите внимание на этот пример от gjohnson :

var express = require('express');
var request = require('supertest');
var app = express();
var router = express.Router();
router.get('/user', function(req, res){
  res.send(200, { name: 'tobi' });
});
app.use(router);
request(app)
  .get('/user')
  .expect('Content-Type', /json/)
  .expect('Content-Length', '15')
  .expect(200)
  .end(function(err, res){
    if (err) throw err;
  });
— Эрих БШульц
источник
1

Мне тоже было интересно, но специально для модульных, а не интеграционных тестов. Это то, что я делаю прямо сейчас,

test('/api base path', function onTest(t) {
  t.plan(1);

  var path = routerObj.path;

  t.equals(path, '/api');
});


test('Subrouters loaded', function onTest(t) {
  t.plan(1);

  var router = routerObj.router;

  t.equals(router.stack.length, 5);
});

Где как раз есть routerObj {router: expressRouter, path: '/api'}. Затем я загружаю подмаршрутизаторы с помощью, var loginRouterInfo = require('./login')(express.Router({mergeParams: true}));а затем экспресс-приложение вызывает функцию инициализации, принимая экспресс-маршрутизатор в качестве параметра. Затем initRouter вызывает router.use(loginRouterInfo.path, loginRouterInfo.router);для монтирования субмаршрутизатор.

Субмаршрутизатор можно протестировать с помощью:

var test = require('tape');
var routerInit = require('../login');
var express = require('express');
var routerObj = routerInit(express.Router());

test('/login base path', function onTest(t) {
  t.plan(1);

  var path = routerObj.path;

  t.equals(path, '/login');
});


test('GET /', function onTest(t) {
  t.plan(2);

  var route = routerObj.router.stack[0].route;

  var routeGetMethod = route.methods.get;
  t.equals(routeGetMethod, true);

  var routePath = route.path;
  t.equals(routePath, '/');
});
— Маркус Роделл
источник
3
Это выглядит действительно интересно. У вас есть еще примеры недостающих частей, чтобы показать, как все это сочетается друг с другом?
— cjbarth 03
1

Чтобы выполнить модульное тестирование вместо интеграционного тестирования, я имитировал объект ответа обработчика запросов.

/* app.js */
import endpointHandler from './endpointHandler';
// ...
app.post('/endpoint', endpointHandler);
// ...

/* endpointHandler.js */
const endpointHandler = (req, res) => {
  try {
    const { username, location } = req.body;

    if (!(username && location)) {
      throw ({ status: 400, message: 'Missing parameters' });
    }

    res.status(200).json({
      location,
      user,
      message: 'Thanks for sharing your location with me.',
    });
  } catch (error) {
    console.error(error);
    res.status(error.status).send(error.message);
  }
};

export default endpointHandler;

/* response.mock.js */
import { EventEmitter } from 'events';

class Response extends EventEmitter {
  private resStatus;

  json(response, status) {
    this.send(response, status);
  }

  send(response, status) {
    this.emit('response', {
      response,
      status: this.resStatus || status,
    });
  }

  status(status) {
    this.resStatus = status;
    return this;
  }
}

export default Response;

/* endpointHandler.test.js */
import Response from './response.mock';
import endpointHandler from './endpointHander';

describe('endpoint handler test suite', () => {
  it('should fail on empty body', (done) => {
    const res = new Response();

    res.on('response', (response) => {
      expect(response.status).toBe(400);
      done();
    });

    endpointHandler({ body: {} }, res);
  });
});

Затем, чтобы выполнить интеграционное тестирование, вы можете смоделировать свой endpointHandler и вызвать конечную точку с помощью supertest .

— fxlemire
источник
0

В моем случае единственное, что я хотел проверить, это то, был ли вызван правый обработчик. Я хотел использовать супертест, чтобы оценить простоту выполнения запросов к промежуточному программному обеспечению маршрутизации. Я использую Typescript a, и это решение, которое сработало для меня

// ProductController.ts

import { Request, Response } from "express";

class ProductController {
  getAll(req: Request, res: Response): void {
    console.log("this has not been implemented yet");
  }
}
export default ProductController

Маршруты

// routes.ts
import ProductController  from "./ProductController"

const app = express();
const productController = new ProductController();
app.get("/product", productController.getAll);

Тесты

// routes.test.ts

import request from "supertest";
import { Request, Response } from "express";

const mockGetAll = jest
  .fn()
  .mockImplementation((req: Request, res: Response) => {
    res.send({ value: "Hello visitor from the future" });
  });

jest.doMock("./ProductController", () => {
  return jest.fn().mockImplementation(() => {
    return {
      getAll: mockGetAll,

    };
  });
});

import app from "./routes";

describe("Routes", () => {
  beforeEach(() => {
    mockGetAll.mockImplementation((req: Request, res: Response) => {
      res.send({ value: "You can also change the implementation" });
    });
  });

  it("GET /product integration test", async () => {
    const result = await request(app).get("/product");

    expect(mockGetAll).toHaveBeenCalledTimes(1);

  });



  it("GET an undefined route should return status 404", async () => {
    const response = await request(app).get("/random");
    expect(response.status).toBe(404);
  });
});

У меня возникли проблемы с тем, чтобы заставить насмешку работать. но использование jest.doMock и определенный порядок, который вы видите в примере, заставляют его работать.

— Альваро
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.