объединение тестов из нескольких файлов с мокко.js

Я пытаюсь объединить всех тестов из нескольких файлов в один файл, что-то вроде этого:



  describe('Controllers', function() {

    describe('messages.js', function() {

      require('./controllertests/messages').test(options);

    })

    describe('users.js', function() {

      require('./controllertests/users').test(options);

    })

  })


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

567   5  

5 ответов:

если вы хотите включить несколько модулей на код describe иерархия, как вы делаете в своем вопросе, то, что вы делаете, в значительной степени это, если вы не хотите написать пользовательский тестовый загрузчик для Мокко. Написание пользовательского загрузчика не будет проще или сделать ваш код яснее, чем то, что у вас уже есть.

вот пример того, как я хотел бы изменить несколько вещей. Элемент test подкаталог в этом примере организован как:

.
└── test
    ├── a
    │   └── a.js
    ├── b
    │   └── b.js
    ├── common.js
    └── top.js

top.js:

function importTest(name, path) {
    describe(name, function () {
        require(path);
    });
}

var common = require("./common");

describe("top", function () {
    beforeEach(function () {
       console.log("running something before each test");
    });
    importTest("a", './a/a');
    importTest("b", './b/b');
    after(function () {
        console.log("after all tests");
    });
});

The importTest функция просто показать, как можно было бы обрабатывать повторение импорта нескольких модулей без необходимости повторять весь describe(... require... каждый раз. Элемент common модуль предназначен для того, что вам нужно использовать в разных модулях набора тестов. Я на самом деле не использую его в top но он может быть использован там, если это необходимо.

отмечу здесь, что beforeEach будет работать его код перед каждым тестом, зарегистрированным в it появляются ли они внутри describe на top или они появляются в любой из модулей, импортированных. С --recursive на beforeEach код должен быть скопирован в каждый модуль или, возможно, у вас будет beforeEach крюк в каждом модуле, который вызывает функцию, импортированную из общего модуля.

и after крюк будет работать после все тесты в комплекте. Это не может быть реплицировано с --recursive. Если вы используете --recursive и добавить код after для каждого модуля он будет выполняться один раз для каждого модуля, а не только один раз для весь

85  
2014-11-07 02:16:06

хотя это не может быть напрямую связано с вопросом, ответ, который я искал, был:

$ mocha --recursive

выполнит все тесты в подкаталогах папки "test". Аккуратный. Экономит необходимость поддерживать список тестов, которые я хочу загрузить и на самом деле просто всегда запускать все.

19  
2016-05-19 21:42:10

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

вот пример того, как вы можете организовать свои тестовые файлы.

.
├── app.js
└── test
    ├── common.js
    ├── mocha.opts
    │
    ├── controllers
    │   ├── messages-controller.js
    │   └── users-controller.js
    │
    └── modles
        ├── messages-model.js
        └── users-model.js

тогда внутри вашего mocha.opts файл, обязательно установите .

мокко.ОПТС

--ui bdd
--recursive

если есть are общий модули, которые вы хотите включить во все файлы, вы можете добавить в . Файлы в корне test каталог будет работать перед файлами во вложенных каталогах.

общие.js

global.chai = require('chai');
global.assert = chai.assert;
global.expect = chai.expect;
chai.should();
chai.config.includeStack = true;

process.env.NODE_ENV = 'test';

// Include common modules from your application that will be used among multiple test suites.
global.myModule = require('../app/myModule');
13  
2014-11-06 14:08:36

Я знаю, что это старый пост, но я хотел перезвонить с тем, что было хорошим решением для меня, очень похожим на метод, предложенный OP.

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

// inside test/index.js

describe('V1 ROUTES', () => {
  require('./controllers/claims.test');
  require('./controllers/claimDocuments.test');
  require('./controllers/claimPhotos.test');
  require('./controllers/inspections.test');
  require('./controllers/inspectionPhotos.test');
  require('./controllers/versions.test');
  require('./services/login.v1.test');
});

describe('V2 ROUTES', () => {
  require('./services/login.v2.test');
  require('./services/dec-image.v2.test');
});

describe('V3 ROUTES', () => {
  require('./services/login.v3.test');
  require('./services/getInspectionPhotosv3.test');
  require('./services/getPolicyInfo.v3.test');
});

describe('ACTIONS', () => {
  require('./actions/notifications.test');
});
3  
2018-05-15 17:19:45 
describe( 'Running automation test, Please wait for all test to complete!'.red, function () {


    var run = require( './Test.js' );

    for ( var i = 0; i < 2; i++ ) {
        run.badLogin();
        run.loginLimited();
        run.acceptJob();
        run.drivingToJob();
        run.arrivedAtJob();
        run.towingJob();
        run.arrivedDestination();
        run.jobComplete();
        run.restrictionLicensePlate();
        run.newNodeMainMenu();
        run.newNodeMainMenuToDrafts();
        run.draftDelete();
        run.resetAllData();
        run.companyVehicle();
        run.actionsScreenClockInOut();
        run.mainMenuLogout();
        run.loginAdmin();
        run.actionsScreenLogout();
    }
} );
-8  
2016-02-01 16:45:24

Comments

    Ничего не найдено.
Click here to cancel reply.