feat(core,common,testing): support overriding middleware for testing

[schiemon]

closes: #4073

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features) I will update them when this PR is ready.

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

The TestingModuleBuilder in the testing package currently has no method available to override middleware à la overrideProvider or overrideModule.

Issue Number: #4073

What is the new behavior?

Now, it is possible to override middleware as it is configured by the configure method of a module:

@Module({})
class AppModule {
  configure(consumer: MiddlewareConsumer) {
    return consumer
      .apply(MiddlewareA, MiddlewareB, MiddlewareC)
      .forRoutes('*');
  }
}

const testingModule = await Test.createTestingModule({
      imports: [AppModule],
})
  .overrideMiddleware(MiddlewareA)
  .use(MiddlewareAOverride)
  .overrideMiddleware(MiddlewareC)
  .use(MiddlewareC1Override, MiddlewareC2Override)
  .compile();

As a by-product, the MiddlewareBuilder is extended by a replace method that allows for swapping out middleware:

builder
  .apply(MiddlewareA, MiddlewareB, MiddlewareC)
  .exclude(route)
  .forRoutes("*")
  .replace(MiddlewareA, MiddlewareAOverride)
  .replace(MiddlewareC, MiddlewareC1Override, MiddlewareC2Override);

Does this PR introduce a breaking change?

• Yes
• No

Other information

[coveralls]

Pull Request Test Coverage Report for Build 1ff17a34-ae9b-45c7-afcc-8778ae899c7c

• 10 of 10 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.006%) to 92.645%

---

Totals
Change from base Build 79434c05-5367-4a7a-a04c-0f91cc807577:	0.006%
Covered Lines:	6474
Relevant Lines:	6988

---

💛 - Coveralls

[Tony133]

Let's leave one line space, for the rest I would say it can be fine

[schiemon]

@kamilmysliwiec Any updates on this?

[kamilmysliwiec]

I'm generally OK with this PR except for this change. Is there any chance we could get rid of this method?

[schiemon]

To remove that method, as far as I see, we need a way to swap the MiddlewareConsumer instance with an implementation that can support middleware replacements. One could accomplish that through the following changes:

First, one enables the injection of MiddlewareModule into a NestApplication:

constructor(
    container: NestContainer,
    private readonly httpAdapter: HttpServer,
    private readonly config: ApplicationConfig,
    private readonly graphInspector: GraphInspector,
    private readonly middlewareModule: MiddlewareModule = new MiddlewareModule(), // `middlewareModule` is now injected and not internally initialized
    appOptions: NestApplicationOptions = {},
) {
...

In the MiddlewareModule itself, we then allow the insertion of a custom MiddlewareBuilder in loadConfiguration like that:

  public async loadConfiguration(
    middlewareContainer: MiddlewareContainer,
    moduleRef: Module,
    moduleKey: string,
    middlewareBuilder?: MiddlewareBuilder, // We now can specify the builder we want to use to configure the modules
  ) {
   ...

    middlewareBuilder =
      middlewareBuilder ??
      new MiddlewareBuilder(
        this.routesMapper,
        this.httpAdapter,
        this.routeInfoPathExtractor,
      );
  ...

With that in place, we can then inject a TestMiddlewareModule that inherits from MiddlewareModule into our NestApplication. Our custom TestMiddlewareModule can then override loadConfiguration which we call the loadConfiguration from the parent MiddlewareModule with a custom TestMiddlewareBuilder. The TestMiddlewareBuilder inherits from the MiddlewareBuilder, which finally supports the replace method we can use.

I am unsure of the consequences of the changes on central classes like NestApplication, but in contrast to the replace method in MiddlewareBuilder, they make sense in the respective classes (I assume this is the reason why you want the method to be removed).

What do you (or others!) think about that?