Use a different database when running tests and package tests

[jankapunkt]

I observed again and again the same problems when testing

• collections are polluted with data from development, this makes the test setup itself invalid from the start
• manipulation of collections during tests keeps docs in development, since the same database is used in dev as in tests. This is especially annoying, when using a dump from production or staging during development and subsequently running tests
• we need to "stub" collections and work on the stubbed versions, which takes time and maintenance effort
• some package still bring their own collections and may have side effects we don't "see" or "access" via package API, which can influence tests, too

Would it be hard to create another database within the portable mongo service, maybe named meteortests or something, which we can reset before testing? That would reduce our test code by nearly half, which is mostly stubbing code

[afrokick]

Currently we use for E2E testing random db name like this(meteor package):

main.js:

import { Meteor } from 'meteor/meteor';
import { Random } from 'meteor/random';

const USE_PACKAGE = process.env.RANDOM_DB_NAME;

if (Meteor.isDevelopment && USE_PACKAGE) {
  if (process.env.MONGO_URL) {
    const nowSeconds = Number.parseInt(new Date().getTime() / 1000);
    let seconds = nowSeconds - 51 * 365 * 24 * 60 * 60;

    if (seconds < 0) {
      seconds = nowSeconds;
    }

    const randomString = `${seconds}${Random.secret(2)}`;
    const newMongoUrl = process.env.MONGO_URL + randomString;

    const newDBName = newMongoUrl.split('/').find(s => s.includes(randomString));

    console.log(`itgenio/random-database: Use db name '${newDBName}'`);

    process.env.MONGO_URL = newMongoUrl;
  }
}

package.js:

/* eslint-disable no-undef */
Package.describe({
  name: 'itgenio:random-db-name',
  version: '1.0.0',
  summary: 'Create random db name',
  documentation: 'README.md',
  debugOnly: true,
});

Package.onUse(function (api) {
  api.versionsFrom('[email protected]');

  api.use(['ecmascript', 'random'], 'server');

  api.mainModule('main.js', 'server');
});

how we run:
RANDOM_DB_NAME=1 meteor npm run start

But yeah, we need to reset some collections manually.

[jankapunkt]

Thank you, I just think that if developer experience is one of Meteor's biggest selling points then this should also apply for testing. We should be able to write valid tests out-of-the-box with less boilerplate. It's just what I think would align with the Meteor philosophy

[jankapunkt]

I will borrow your code snippet for our tests and see if this helps in the meantime ❤️