Improve TypeORM Testing Documentation

[jelling]

I'm submitting a...

[X] Documentation issue or request

Current behavior

When testing classes that use TypeORM using Jest, there is inconsistent behavior if the TypeORM database connection is established in a Jest setupFile, like:

createConnection()

This worked for most for all of our entities except for one where it gave the dreaded "no metadata found" TypeORM error. The same entity worked fine when not running inside a TestModule so the entity definition wasn't the issue. It's possible there was a race condition but all of the other entities worked consistently.

Eventually, I figured out that the proper way to use TypeORM inside of a Jest Spec is like this:

import { TypeOrmModule } from "@nestjs/typeorm";
...

describe('Example Service', async function() {

  beforeAll(async () => {
    const module: TestingModule = await Test.createTestingModule({
      imports: [TypeOrmModule.forRoot()],
      providers: [...services],
    }).compile();

  });

...

I.e. always inject the Nest.Js TypeORM module into your testing module.

Expected behavior

Update the testing section of these docs to show an example using a real database as well as the mocked example.

[fan-tom]

You saved my day, it seems to me that docs must have a scetion that describes what to do if you just want to use existing database in tests

[kenberkeley]

Workaround: https://stackoverflow.com/a/59483875/5172890

[codiophile]

I spent most of yesterday figuring out how to get my e2e tests working. The documentation really wasn't very helpful.

The auto-generated e2e test imports the app module in the testing module, so I thought that was the way to do it. However, my app module includes both TypeORM and BullMQ, so it tries to connect to both the database and Redis. I figured I'd just .overrideModule(TypeOrmModule) (same with the BullModule) to replace it with a mock, but at that point it seems like it's already too late. Jest wouldn't finish, because there were both db connections and Redis connections keeping the process running.

In the end, the solution ended up being to not test the app module itself, but to create a testing module that includes only the parts of the app module that I intend to test and then auto-mock all dependencies I don't need custom mocks for. I also created an e2e test where instead of mocking the TypeORM repository, I simply provide a TypeOrmModule initialised with an in-memory SQLite database. I found this very useful and neither of these two approaches are documented. It would have saved me a lot of time if they were.

I'm happy to open a PR for this, but I thought I'd start by checking if my understanding is correct and this is in fact the way to do it.