Merge pull request #2102 from jmcdo29/feat/auto-mock

feat: add new documentation around auto-mocking capabilities

Author: kamilmysliwiec

content/fundamentals/unit-testing.md

@@ -160,6 +160,41 @@ Instead of using the production version of any provider, you can override it wit
 
 <app-banner-courses></app-banner-courses>
 
+#### Auto mocking
+
+Nest also allows you to define a mock factory to apply to all of your missing dependencies. This is useful for cases where you have a large number of dependencies in a class and mocking all of them will take a long time and a lot of setup. To make use of this feature, the `createTestingModule()` will need to be chained up with the `useMocker()` method, passing a factory for your dependency mocks. This factory can take in an optional token, which is an instance token, any token which is valid for a Nest provider, and returns a mock implementation. The below is an example of creating a generic mocker using [`jest-mock`](https://www.npmjs.com/package/jest-mock) and a specific mock for `CatsService` using `jest.fn()`.
+
+```typescript
+const moduleMocker = new ModuleMocker(global);
+
+describe('CatsController', () => {
+  let controller: CatsController;
+
+  beforeEach(async () => {
+    const moduleRef = await Test.createTestingModule({
+      controllers: [CatsController],
+    })
+    .useMocker((token) => {
+      if (token === CatsService) {
+        return { findAll: jest.fn().mockResolveValue(results) };
+      }
+      if (typeof token === 'function') {
+        const mockMetadata = moduleMocker.getMetadata(token) as MockFunctionMetadata<any, any>;
+        const Mock = moduleMocker.generateFromMetadata(mockMetadata);
+        return new Mock();
+      }
+    })
+    .compile();
+    
+    controller = moduleRef.get(CatsController);
+  });
+})
+```
+
+> info **Hint** A general mock factory, like `createMock` from [`@golevelup/ts-jest`](https://github.com/golevelup/nestjs/tree/master/packages/testing) can also be passed directly.
+
+You can also retrieve these mocks out of the testing container as you normally would custom providers, `moduleRef.get(CatsService)`.
+
 #### End-to-end testing
 
 Unlike unit testing, which focuses on individual modules and classes, end-to-end (e2e) testing covers the interaction of classes and modules at a more aggregate level -- closer to the kind of interaction that end-users will have with the production system. As an application grows, it becomes hard to manually test the end-to-end behavior of each API endpoint. Automated end-to-end tests help us ensure that the overall behavior of the system is correct and meets project requirements. To perform e2e tests we use a similar configuration to the one we just covered in **unit testing**. In addition, Nest makes it easy to use the [Supertest](https://github.com/visionmedia/supertest) library to simulate HTTP requests.
@@ -243,26 +278,27 @@ describe('Cats', () => {
 >
 > ```ts
 > let app: NestFastifyApplication;
-> 
+>
 > beforeAll(async () => {
 >   app = moduleRef.createNestApplication<NestFastifyApplication>(
 >     new FastifyAdapter(),
 >   );
 >
 >   await app.init();
 >   await app.getHttpAdapter().getInstance().ready();
-> })
-> 
+> });
+>
 > it(`/GET cats`, () => {
 >   return app
 >     .inject({
 >       method: 'GET',
->       url: '/cats'
->     }).then(result => {
->       expect(result.statusCode).toEqual(200)
->       expect(result.payload).toEqual(/* expectedPayload */)
+>       url: '/cats',
+>     })
+>     .then((result) => {
+>       expect(result.statusCode).toEqual(200);
+>       expect(result.payload).toEqual(/* expectedPayload */);
 >     });
-> })
+> });
 > ```
 
 In this example, we build on some of the concepts described earlier. In addition to the `compile()` method we used earlier, we now use the `createNestApplication()` method to instantiate a full Nest runtime environment. We save a reference to the running app in our `app` variable so we can use it to simulate HTTP requests.