feat(testing): allow omitting httpAdapter arg on createNestApplication

[micalevisk]

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)

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?

When using createNestApplication from Test.createTestingModule(), the only way to pass options while still using the default http adapter is by passing undefined (or any falsy value) as the first arg like this:

moduleFixture = await Test.createTestingModule({}).compile()
app = moduleFixture.createNestApplication(undefined, { bodyParser: false })

but to me this interface doesn't feels good from DX POV. See nestjs/docs.nestjs.com#2119 (which can be closed if we merge this PR)

What is the new behavior?

the options must be supplied in the first arg if we want to use the default http adatper, like so:

app = moduleFixture.createNestApplication({ bodyParser: false }) // THIS IS NEW

// Same as:
app = moduleFixture.createNestApplication(new ExpressAdapter(), { bodyParser: false })

which I believe is more intuitve than passing undefined. The old version isn't allowed anymore

Does this PR introduce a breaking change?

• Yes
• No

[coveralls]

Pull Request Test Coverage Report for Build e991088d-6a88-4808-a8e2-6d3ba41d11d0

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 0.0%

---

Totals
Change from base Build b014cf54-5050-41eb-bd7a-750721daafe5:	0.0%
Covered Lines:	0
Relevant Lines:	0

---

💛 - Coveralls

[micalevisk]

I notice that the following was not using the fastify adapter

nest/integration/cors/e2e/fastify.spec.ts

Line 33 in 7b112dd

app = module.createNestApplication<NestFastifyApplication>();

After using it, the integration tests starts failing with Uncaught TypeError: Cannot read properties of undefined (reading 'length') 🤔 Let's track this here: #9652

[Tony133]

@micalevisk it has been fixed in this PR #9653, so the error as you said does not refer to your PR you made

[micalevisk]

this PR is done but I'll mark it as a draft until those changes made on cors/e2e/fastify.spec.ts and raw-body/e2e/fastify.spec.ts goes to the branch 9.0.0

[kamilmysliwiec]

I just merged the latest changes from master to 9.0.0. Not sure if that unblocks you @micalevisk(?)

[micalevisk]

the file cors/e2e/fastify.spec.ts is not ready yet. If I fix below to use fastify instead the test suite will fail

nest/integration/cors/e2e/fastify.spec.ts

Line 33 in 36eda24

app = module.createNestApplication<NestFastifyApplication>();

[kamilmysliwiec]

@micalevisk would you like to look into how we can fix it? if you can't find a solution, can always add .skip there - this test doesn't work as expected either way

[micalevisk]

Using the latest commit on 9.0.0 (f41ee3d) as the base of this branch, we got an error due to version mismatch (I guess), which is not the one I expected 🤔

btw I didn't manage to make the integration tests run locally.

[kamilmysliwiec]

@micalevisk updating @fastify/cors to v8 should fix this issue

[kamilmysliwiec]

Tests are failing now @micalevisk

[micalevisk]

using the latest version of the branch 9.0.0, and after upgrading @fastify/cors to v8, we got this:

Also, locally, even using v7 and rm -rf node_modules && npm ci, I got this:

---

fell free to copy the changes I made in this branch if you manage to fix that. Idk what to do by now

[Tony133]

@micalevisk i had also received a similar error during some PRs (for example, see #9768), but had no idea how to fix it.

I'm still not sure at the moment, still exploring a little, but I think this problem you had opened is the starting point to solve it #9629.