uniendo pruebas de varios archivos con mocha.js

Estoy tratando de unir todas las pruebas de varios archivos en un solo archivo, algo como esto:

  describe('Controllers', function() {
    describe('messages.js', function() {
      require('./controllertests/messages').test(options);
    })
    describe('users.js', function() {
      require('./controllertests/users').test(options);
    })
  })

Estoy bastante seguro de que esta no es la mejor manera de unirme a pruebas, tengo algunas dificultades para encontrar ejemplos de cómo hacer esto: s

Si desea incluir varios módulos en su describejerarquía como lo está haciendo en su pregunta, lo que está haciendo es prácticamente eso , a menos que desee escribir un cargador de prueba personalizado para Mocha. Escribir el cargador personalizado no sería más fácil ni haría su código más claro de lo que ya tiene.

Aquí hay un ejemplo de cómo cambiaría algunas cosas. El testsubdirectorio en este ejemplo está organizado como:

.
└── 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");
    });
});

La importTestfunción es solo para mostrar cómo sería posible manejar la repetición de la importación de varios módulos sin tener que volver a escribir todo describe(... require...cada vez. El commonmódulo está destinado a contener lo que necesita usar en varios módulos del conjunto de pruebas. En realidad, no lo estoy usando, toppero podría usarse allí, si es necesario.

Voy a señalar aquí que la beforeEachva a ejecutar su código antes de cada prueba única registrada con itsi aparecen dentro de la describeen top, o que aparecen en cualquiera de los módulos importados . Con --recursive, el beforeEachcódigo tendría que copiarse en cada módulo o tal vez tendría un beforeEachgancho en cada módulo que llama a una función importada de un módulo común.

Además, el aftergancho se ejecutará después de todas las pruebas en la suite. Esto no se puede replicar con --recursive. Si usa --recursivey agrega el código de aftera cada módulo, se ejecutará una vez por módulo en lugar de solo una vez para toda la prueba.

El hecho de que todas las pruebas aparezcan bajo un solo topencabezado no se puede replicar con --recursive. Con --recursivecada archivo podría haberlo hecho, describe("top"pero esto crearía un nuevo topencabezado para cada archivo.

common.js:

var chai = require("chai");

var options = {
    foo: "foo"
};

exports.options = options;
exports.chai = chai;
exports.assert = chai.assert;

Usar un módulo llamado commonasí es algo que he hecho en algunas de mis suites de prueba para evitar tener que hacer requireun montón de cosas una y otra vez y mantener variables o funciones globales de solo lectura que no mantienen el estado. Prefiero no contaminar el globalobjeto como en la respuesta de thgaskell porque este objeto es verdaderamente global y accesible incluso en bibliotecas de terceros, su código puede estar cargando. Esto no es algo que encuentre aceptable en mi código.

a/a.js:

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

it("blah a", function () {
    console.log(options.foo);
    assert.isTrue(false);
});

b/b.js:

it("blah b", function () {});

Aunque esto puede no estar directamente relacionado con la pregunta, la respuesta que estaba buscando era:

$ mocha --recursive

Ejecutará todas las pruebas en subdirectorios de la carpeta "prueba". Ordenado. Me ahorra tener que mantener una lista de pruebas que quiero cargar y, en realidad, siempre ejecutarlo todo.

No hay nada que le impida ejecutar varios archivos de prueba. Generalmente, cada prueba no debe depender de los resultados de otra prueba, por lo que compartir variables no es algo que le gustaría hacer.

Este es un ejemplo de cómo podría organizar sus archivos de prueba.

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

Entonces dentro de tu mocha.opts archivo, asegúrese de configurar la --recursiveopción.

mocha.opts

--ui bdd
--recursive

Si no están módulos comunes que desea incluir en todos los archivos, se puede añadir que el common.jsarchivo. Los archivos en la raíz del testdirectorio se ejecutarán antes que los archivos en directorios anidados.

common.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');

Sé que esta es una publicación antigua, pero quería intervenir con lo que ha sido una buena solución para mí, muy similar al método propuesto por OP.

El proyecto en el que estoy trabajando está bien probado y las pruebas siguen creciendo. Terminé usando requireporque es sincrónico y, por lo tanto, hace que sea un poco más fácil componer sus pruebas sin demasiados cambios en la arquitectura:

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

Tuve un problema similar en el que tenía un montón de pruebas para clases en la misma categoría y quería agruparlas para facilitar su visualización en un IDE. Todas mis pruebas y código ya usaban módulos ES6; no quería reescribirlos todos para usarlos requirecomo vi en otros ejemplos.

Lo resolví describeexportando mi "agrupación" y luego importándolo a mis archivos de prueba y agregándolos programáticamente al archivo importado describe. Terminé creando un método auxiliar para abstraer todas las tuberías.

En someCategory.spec.js

const someCategory= describe("someCategory", () => {});


// Use this just like a regular `describe` to create a child of this scope in another file
export default function describeMember(skillName, testFn) {
  return describe(skillName, function configureContext() {
    // Make context a child of `someCategory` context
    function Context() {}
    Context.prototype = someCategory.ctx;
    this.ctx = new Context();
    // Re-parent the suite created by `describe` above (defaults to root scope of file it was created in)
    this.parent.suites.pop();
    someCategory.addSuite(this);
    // Invoke the fn now that we've properly set up the parent/context
    testFn.call(this);
  });
}

En pruebas individuales:

import { default as describeCategoryMember } from './someCategory.spec';

describeCategoryMember('something', () => {
    describe('somethingElse', () => {
        ...
    });

    it('a test', () => {
        ...
    });
})

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