mardi 26 décembre 2017

Right way to terminate testing mongodb server

We are using mongodb-prebuilt package for perform unit/integration testing (CI/CD) for the developed software, which performs interaction with mongodb database.

Common use case is following: launch testing mongodb server with prebuild package, perform test suite execution and then terminate server. First and second items are done easily, but third one causes some problems.

If mongodb-prebuilt-started server had not been terminated, test runner will hang forever. Instead, if try to terminate server by testConnection.command({ shutdown: 1 }) command, then unhandledRejection fires, which refers on closed connection - which of course had been forcefully closed by stopping the server.

Which is right way to dispose mongodb-prebuilt at afterAll test section? Test engine is jest, but it does not matter strongly.
Example code here:

import { MongodHelper } from 'mongodb-prebuilt';
import { MongoClient } from 'mongodb';

describe('Test suite', () => {
    let testConnection;
    beforeAll(async () => {
        const mongodHelper = new MongodHelper(['--port', "27018"]);
        await mongodHelper.run();
        testConnection = await MongoClient.connect(`mongodb://localhost:27018/admin`);
    });
    afterAll(async () => {
        await testConnection.dropDatabase();
        await testConnection.command({ shutdown: 1 });
        await testConnection.close();
        testConnection = null;
    });
    /* Here follows some test suite that uses testConnection  */
}

There was some attempts to solve problem:

1) Don't await testConnection.command({ shutdown: 1 })-generated promise, and instantly initiate client connection closing - it works on some machines, but most likely depends on execution speed, so works unstable.

2) Because of client connection termination at the end of the tests does not matter strongly - it's possible to setup process.on('unhandledRejection', ...) handler in afterAll section and just mute exception - works well, but seems to be ideologically incorrect

So, maybe is there stereotypical solution for original task?

IMPORTANT NOTE: suggesting use some mock packages instead live mongodb is not appropriate at all, since developed software is specific adapter for mongodb and should respect all aspects of live database, including timings, admin commands and so on

Aucun commentaire:

Enregistrer un commentaire