Testing Adonisjs app behavior with different env-vars

[nidomiro]

I'm coming from nestjs and jest / vitest and currently evaluate if japa is a better test runner for my adonisjs app.

I came across the problem that I found no way of tempering with the env-vars before the app starts for my test.
In my nestjs tests I would do something like:

// pseudocode
it('my fancy test', () => {
const startedContainer = // start the testcontainer
process.env.SOME_VAR = startedContainer.xyz
const app = //start my nest app

expect(...) // test the behavior of the change

})

Is this possible with japa and adonisjs?

My current usecase is that I need to restart a container on every test run, since it does not support deleting data. But other usecases would be to test if e.g. feature-toggles work.

For how to get testcontainers working in general I found https://github.com/orgs/adonisjs/discussions/4453 , but sadly this is not as useful for my case, since I want a "changing container"

[thetutlage]

I would need a bit more info to share an accurate way to mutate env variables for your use-case. If you just want to override an env variable, then you may use the .env.test file, but I think you are not looking for that.

In AdonisJS, the app is booted once and then all tests are executed against the same instance. Which means, the app is not re-booted for every single test or test file.

What I would like to know is

• Do you want to start the test container once before the app starts, get its running port and set that as the environment variable?
• Or, do you want to start the test container before every test and get its running port and set that as the environment variable?
• Does other parts of your app relies on that test container? For example, you are running a database container and now you want Lucid to reboot itself with the new credentials?

[nidomiro]

Thanks for your Answer.

Yes you are correct, changing config in the .env.test file is not enough, since it is not dynamic.

To be more specific with my question, unit tests are not a problem, since Unit tests will mock all external dependencies anyway. My question focuses on functional tests, where I test the whole application more or less as a grey- or black-box.
In my specific use-case I'm developing an event-sourced application and the container I want to start with testcontainers is eventsourcingdb. As you may already know, in event-sourcing there is no delete, so If I test some aspects of the api, like creating a user, renaming a user, creating another special user and listing users, I'll get the problem, that the testdata for e.g. listing users is dirty, since it was "polluted" by the other tests and cannot be cleaned up.
My general solution for such cases is to just stop the container and app and restart them. This purges the existing data. But that would need to happen before every single test run.

Another usecase is, that I would like to test if a feature-toggle works as expected. For that I would need to set the toggle to false in one test and test the app behavior, then in another test set it to true and test the behavior again.

The easiest, most secure (but definitely not most performant) solution for "black-box" tests like this to change the stuff I want, boot the application and after each test run tear everything down again.

[thetutlage]

Alright, thanks for presenting these use-cases.

AdonisJS approaches tests in a slightly different manner. We start the application once as a long-running process and write tests against it. This approach has a couple of benefits.

• Tests are super quick, since they do not have to pay the performance penalty of restarting the app before every test.
• It mimics the nature of a long-running web server. In production, multiple requests will hit the same process multiple times, hence it's better to have the same behavior during testing to catch issues like memory leaks or race conditions (that are hard to find when every test has a fresh state).

However, in your case, you want to reboot external services and then make your application react to it. Ideally, it won't be that difficult.

Can you share some concrete example of your eventsourcingdb container. Maybe create a fresh AdonisJS app, write two tests and share a reproduction of things not working and then maybe I can share a solution to make them work

[nidomiro]

Thanks for your helpful answer.
Unfortunately I cannot do that currently. However the container itself is public: https://hub.docker.com/r/thenativeweb/eventsourcingdb

I think I can work around the requirement of having a clean app before every test. One solution for testing the listing of users would be to check the endpoint before, add some other users and then check the delta. That way it does not matter, if the state is "dirty".

The use-case with testing feature flags is not relevant for this project right now, it was more a general question. But it will probably become relevant in the future.

Out of curiosity, how would I start the app when using vite as test-framework? What I found so far, japa doesn't run the app, the app will run japa after init. My idea would be to copy the content of the files in bin/ and create my own app instance via export const adonisApp = new Ignitor(APP_ROOT, { importer: IMPORTER }), which I can configure to my liking for the test.
Is this the correct path, I'm on?

[nidomiro]

I got it working with vitest:

create another file bin/test.vite.ts:

/*
|--------------------------------------------------------------------------
| Test runner entrypoint for usage with vitest
|--------------------------------------------------------------------------
|
*/

process.env.NODE_ENV = 'test';

import 'reflect-metadata';
import { Ignitor } from '@adonisjs/core';

/**
 * URL to the application root. AdonisJS need it to resolve
 * paths to file and directories for scaffolding commands
 */
const APP_ROOT = new URL('../', import.meta.url);

/**
 * The importer is used to import files in context of the
 * application.
 */
const IMPORTER = (filePath: string) => {
    if (filePath.startsWith('./') || filePath.startsWith('../')) {
        return import(new URL(filePath, APP_ROOT).href);
    }
    return import(filePath);
};

process.send = undefined; // Prevent Adonis from sending messages via process.send and confuse vitest

export const adonisApp = new Ignitor(APP_ROOT, { importer: IMPORTER }).tap(app => {
    app.booting(async () => {
        await import('#start/env');
    });
    app.listen('SIGTERM', () => app.terminate());
    app.listenIf(app.managedByPm2, 'SIGINT', () => app.terminate());
});

and in your vitest config:

import { defineConfig } from 'vitest/config';

export default defineConfig({
    test: {
        environment: 'node',
        pool: 'forks',
        poolOptions: {
            forks: {
                // execArgv: ['--import', 'tsx'],
                execArgv: ['--import', 'ts-node-maintained/register/esm'],
            },
        },
// [...]
    },
});

then you can write vitest files like this:

import { beforeAll, describe, expect, test } from 'vitest';
import { adonisApp } from '../../../bin/test.vite.js';
import { type ApplicationService } from '@adonisjs/core/types';
import { Logger } from '@adonisjs/core/logger';

describe('adonisjs-vitest', () => {
    let app: ApplicationService;
    beforeAll(async () => {
        await adonisApp.httpServer().start();
        const appOrUndefined = adonisApp.getApp();
        if (!appOrUndefined) {
            throw new Error('Failed to get Adonis application instance');
        }
        app = appOrUndefined;

        return () => adonisApp.terminate();
    });

    test('sample test', async () => {
        const logger = await app.container.make(Logger);
        expect(logger).toBeDefined();
        logger.info('TestLogEntry');
    });
});

[thetutlage]

@nidomiro Thanks for sharing this. I am sure it will help others trying to use Vitest :)