Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

Commit bd4e7e2

Browse files
docs(sql.md): Add documentation for testing with database
This was requested in #246 and since I was recently struggling to set this up in one of my own projects, I have it fresh in memory how to do this. If this was in the documentation when I was implementing this, it would have saved me a lot of time. There are many dodgy approaches to testing NestJS applications with a test database on the Internet and an official recommended way would be most helpful. Resolves #246 
1 parent d940f58 commit bd4e7e2

File tree

1 file changed

+28
-0
lines changed

1 file changed

+28
-0
lines changed

‎content/techniques/sql.md

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -603,6 +603,34 @@ export class UsersModule {}
603603

604604
Now a substitute `mockRepository` will be used as the `UsersRepository`. Whenever any class asks for `UsersRepository` using an `@InjectRepository()` decorator, Nest will use the registered `mockRepository` object.
605605

606+
Sometimes, however, it is useful to test with an actual database, not the least, because it saves you from implementing potentially complex mocks of your TypeORM repositories. Sometimes, the logic you want to test is implemented in the database itself. While you can test with any database supported by [TypeORM](https://typeorm.io/), an in-memory SQLite database would be recommended for most use cases, as it provides the best performance, and has no external dependencies.
607+
608+
```typescript
609+
beforeEach(async () => {
610+
const moduleFixture: TestingModule = await Test.createTestingModule({
611+
imports: [
612+
TypeOrmModule.forRoot({
613+
type: 'better-sqlite3',
614+
database: ':memory:',
615+
dropSchema: true,
616+
autoLoadEntities: true,
617+
synchronize: true,
618+
}),
619+
TypeOrmModule.forFeature([User]),
620+
],
621+
providers: [UsersService],
622+
controllers: [UsersController],
623+
}).compile();
624+
625+
app = moduleFixture.createNestApplication();
626+
await app.init();
627+
});
628+
```
629+
630+
> info **Hint** It is recommended to keep the test database configuration in a separate file, to not have to repeat it in every test.
631+
632+
> warning **Warning** If you import a module, in your testing module, that already imports the `TypeOrmModule`, the test database will not automatically override that configuration and you will likely see the `TypeOrmModule` trying to connect to the application database. To avoid this, it is recommended that you instead import the controllers and providers you need from that module and [auto-mock](/fundamentals/testing#auto-mocking) whatever dependencies aren't relevant to your test. This is generally a good approach to avoid initializing external dependencies that you don't want to load in your tests.
633+
606634
#### Async configuration
607635

608636
You may want to pass your repository module options asynchronously instead of statically. In this case, use the `forRootAsync()` method, which provides several ways to deal with async configuration.

0 commit comments

Comments
(0)

AltStyle によって変換されたページ (->オリジナル) /