Nx: node-app nestjs e2e test module

[xmlking]

Prerequisites

Please answer the following questions for yourself before submitting an issue.
YOU MAY DELETE THE PREREQUISITES SECTION.

• [x] I checked the documentation and found no answer
• [x] I am running the latest version
• [x] I checked to make sure that this issue has not already been filed
• [x] I'm reporting the issue to the correct repository (not related to Angular, AngularCLI or any dependency)

Expected Behavior

ng g node-app api --framework=nestjs should generate both api and api-e2e modules

Current Behavior

only generate api module

Similar to webApps , we need e2e testing for node-apps
Proposal :
we can generate NestJS e2e module something like this https://github.com/xmlking/ngx-starter-kit/tree/develop/apps/api-e2e

and angular.json entry
https://github.com/xmlking/ngx-starter-kit/blob/develop/angular.json#L286

then we can do e2e tests with:

ng e2e api-e2e
ng e2e api-e2e --watch

[atul221282]

+1

[gperdomor]

any update/plan about this?

[gperdomor]

@FrozenPandaz @vsavkin any chance to fix this for Nx 8 release?

[xmlking]

Thought for feedback:
Would it be better if we have e2e module within main app? For both angular and nestjs apps
This why, We can have fewer apps in angular.json

    src
    e2e
backend
    src
    e2e

[gperdomor]

@xmlking I prefer that too, is a cleaner solution... In fact, both angular and NestJS have e2e test in some folder inside the main project folder when are created with their official cli...

NestJS directory structure (created using nest new nests-app):

├── README.md
├── nest-cli.json
├── node_modules
├── nodemon-debug.json
├── nodemon.json
├── package-lock.json
├── package.json
├── src
├── test ---> e2e tests resides here
├── tsconfig.build.json
├── tsconfig.json
└── tslint.json

Angular directory structure (created using ng new angular-app):

├── README.md
├── angular.json
├── e2e ---> e2e tests resides here
├── node_modules
├── package-lock.json
├── package.json
├── src
├── tsconfig.json
└── tslint.json

[xmlking]

in the above commit, I merged e2e projects with corresponding parent projects (both for angular/cypress and nestjs)

they are working fine with following commands

ng e2e api
ng e2e webapp

ng lint api will lint files in src and e2e

wish cypress builder support outputPath option like @angular-devkit/build-angular, so that we can keep cypress.json relative paths free (e.g. ../../../dist/apps/...)

[gperdomor]

@xmlking can you send a PR to this repo? 🙏

[Jordan-Hall]

I prefer the existing approach. In a mono repo, wouldn't it be better to split these out of the common application because companies tend to do smoke screen tests now and then on the live system periodically?

[xmlking]

One of the reason I am motivated to merge e2e and main src in single project is , direct e2e dependency on main app code, https://github.com/xmlking/ngx-starter-kit/blob/develop/apps/api/e2e/src/app.e2e-spec.ts#L4

[Jordan-Hall]

@xmlking that's because of how the tests are done using jest and are only an issue with the node applications. In the example, the "end2end" testing is actually done more on a unit test/integration perspective rather than the real "end2end"

I think they some confusion over the testing. This to me doesn't feel like end2end and it should be done using jest personally. When it comes to the frontend you use protector or cypress that files to a URL. rather than what happening in the example which is you building a local version of the site to test. the node API.

[FrozenPandaz]

For starters, I don't think this is in scope for 8.0.0. We're focused on making sure repackaging is a good experience and migrating to the new architect API. But I would like to join the discussion to share my thoughts and work towards a plan for 8.x

My main motivation for having an e2e project for a node-app is for repositories that contain _only_ backend code. Such an e2e project would likely use something like supertest (as the nest-cli does) via jest to _actually_ make a request to a running server and check the response. Cypress would likely not be a good choice. It would probably not be generated by default as being full-stack is a major benefit but there would be an option for it. We could probably create a builder composing around the @nrwl/node:execute and @nrwl/jest:jest builders.

As for having the e2e tests within the application projectRoot, I feel more strongly against this. My reason is that e2e tests could depend on more than just a single application. For example, login might be a separate app altogether which can be part of the e2e test suite.

[gperdomor]

@FrozenPandaz well, I think that the node-app should be able to be tested no matter which approach is decided... The nest template provides a good structure for e2e tests using supertest like you mention... I don't know how complex would be using the same e2e tests generated by the the nest-cli

[Jordan-Hall]

I'm with @frozenPandaz can test e2e on node application is excellent. But my main reservation is it going to the main application root.

I like splitting the responsibility of my backend code, for example, having a microservice that deals with database connections and another for authentication etc.

[gperdomor]

as Nx 8 was released, how can we deal with nestjs e2e test? this will be added in the future?

[gperdomor]

ping @FrozenPandaz @vsavkin

[vsavkin]

As Jason mentioned the @nrwl/node:execute and @nrwl/jest:jest builders should be sufficient to implement an e2e test project.

Run:

ng g @nrwl/nest:app api
ng g @nrwl/node:app api-e2e

Next, rename the test target in the api-e2e project into e2e, and write tests using say supertest.

Having said that, I think it is a good idea to generate an e2e test project for both express and nest apps. Could anyone write a proposal of what it will look like for both express and nest projects/

[gperdomor]

@vsavkin what do you mean with rename the test target in the api-e2e project into e2e?

[gperdomor]

@vsavkin omit my last question... I understand 👍

I delete the src folder in api-e2e and update the angular.json like that:

    ...
    "api-e2e": {
      "root": "apps/api-e2e",
      "sourceRoot": "apps/api-e2e/src",
      "projectType": "application",
      "prefix": "api-e2e",
      "schematics": {},
      "architect": {
        "lint": {
          "builder": "@angular-devkit/build-angular:tslint",
          "options": {
            "tsConfig": [
              "apps/api-e2e/tsconfig.app.json",
              "apps/api-e2e/tsconfig.spec.json"
            ],
            "exclude": ["**/node_modules/**", "!apps/api-e2e/**"]
          }
        },
        "e2e": {
          "builder": "@nrwl/jest:jest",
          "options": {
            "jestConfig": "apps/api-e2e/jest.config.js",
            "tsConfig": "apps/api-e2e/tsconfig.spec.json"
          }
        }
      }
    }

Basic test:

// some-test-file.spec.ts
import { Test, TestingModule } from '@nestjs/testing';
import * as request from 'supertest';
import { AppModule } from '../../api/src/app/app.module'; // <----- fails

describe('AppController (e2e)', () => {
  let app;

  beforeEach(async () => {
    const moduleFixture: TestingModule = await Test.createTestingModule({
      imports: [AppModule]
    }).compile();

    app = moduleFixture.createNestApplication();
    await app.init();
  });

  it('/ (GET)', () => {
    return request(app.getHttpServer())
      .get('/')
      .expect(200)
      .expect({ message: 'Welcome to api!' });
  });
});

running npm run e2e -- --project=api-e2e works fine but npm run lint -- --project=api-e2e fails with this error: library imports must start with @nx-platform/

Also glad to see this will be improved and supported in Nx 9

[tfalvo]

I followed @vsavkin advice, and as @gperdomor, I created a new app api-e2e, and rename test target to e2e.

Then, in the spirit of Nx modularization, I moved code of my NestJs api application to at least 2 libs for instance :

• api-feature (with controller/service for one feature)
• api-application (with app.module.ts only)

It's clear, that I have a very specific lib with app.module.ts, but it's not a real problem for me. However, if we don't want to create this lib, we could consider to leave AppModule very small, with only main imports. So it's easy to recreate it both in app and app-e2e.

Finally, I imported theses 2 libs into both api and api-e2e application.
And... it works like a charm !

ng e2e api-e2e
ng lint api-e2e

Really interested to receive your feedback/comments.

Thank you guys for your sharing, and all your great job !
I'm a huge fan of Nx. 👍

[gperdomor]

@tfalvo can you send us the link of the repo?

[johannesschobel]

the solution described by @vsavkin and @gperdomor works perfectly.. However, a more "clean" approach would be to bootstrap it like @tfalvo described in his post.. will dive into this later, i guess :)

cheers to all of you for making nrwl such an awesome experience!

[myflowpl]

Hi @gperdomor, vsavkin solution with your code samples also works for me very well.
Did you find fix for linting ?

I did some workaround by adding new entry in tsconfig.json

tsconfig.json -> compilerOptions -> paths

"paths": {
  "@app/api/*": ["apps/api/src/app/*"]
}

then in your some-test-file.spec.ts file

// import { AppModule } from '../../api/src/app/app.module'; // <----- fails linting
import { AppModule } from '@app/api/app.module'; // <----- All files pass linting.

Hope to see this in Nx v10

Good job guys !

[FrozenPandaz]

Hi, sorry about this.

This was mislabeled as stale. We are testing ways to mark _not reproducible_ issues as stale so that we can focus on actionable items but our initial experiment was too broad and unintentionally labeled this issue as stale.

[luqezman]

@tfalvo do you think having e2e for nestjs is not tricky and stable?

[tfalvo]

Hi @luqezman, could you precise your question please. e2e with NestJS or e2e with NestJS + NX, or just e2e vs simple unit test??...

[beeman]

Having said that, I think it is a good idea to generate an e2e test project for both express and nest apps. Could anyone write a proposal of what it will look like for both express and nest projects/

Hey @vsavkin , @DominikPieper and I took some time to go over this, and we came up with the proposal below.

A (manual) implementation of this structure with a Nest API can be found here.

The only downside to this proposal so far is that AppModule requires a path-based import:

Which makes WebStorm complain:

It would be great if we could have a way to address this, without having to change too much (if anything at all) on the side of the application.

Looking forward to your feedback :)

---

Proposal: Create e2e projects for Node apps in Nx Workspace

Backend applications in an Nx Workspace (generated with the @nrwl/node, @nrwl/express and @nrwl/nest plugins) don't generate e2e application, unlike frontend projects.

The reasons behind this is that when e2e tests that are added to a frontend project, they will generally also test the backend.

However, in some cases it makes sense to add an e2e test for Node-based projects, for instance if there is only backend code in your workspace.

Solution

Existing projects

Create a new schematic to @nrwl/node plugin called e2e-app. The schematic takes as an argument the name of an existing project (of type 'application') in the workspace:

nx generate @nrwl/node:e2e-app api

Running this schematic creates a new project in the workspace file called api-e2e, and add 2 architects: e2e and lint.

The structure of the generated app will be very similar to the -e2e apps that are generated for the frontend.

Having this schematic being standalone allows people to opt in to having an e2e test for a backend project, for instance in an existing Nx Workspace.

New projects

Additionally, when generating a new project using @nrwl/node:app, @nrwl/express:app or @nrwl/nest:app, the user should be able to opt-in to creating this -e2e application.

For instance, using this command:

nx generate @nrwl/nest:app api --e2e

Will result in a structure like this:

apps/api/
apps/api-e2e/

[khalilou88]

Hi all, I don't think we need a e2e for api projects. For me its only integrations tests that should live inside the api projects.
with the actual solution we don't need to import AppModule from another project (e2e).
If you choose to use a e2e project, I think we need to use an url for the api and don't import code from it.

[AliYusuf95]

I agree with @khalilou88,
e2e test shouldn't import the files from other projects, @beeman this is the way to solve that 😄 .
We need a solution similar to the one that used in frontend e2e projects, which is serve the frontend app then execute the tests files. As what @nrwl/cypress:cypress builder does.

// example configuration
// ... node-e2e
"e2e": {
    "builder": "@nrwl/jest:jest", // <--- update/create new builder to accept `devServerTarget` option
    "options": {
        "jestConfig": "apps/node/jest.config.js",
        "devServerTarget": "backend:serve"  // <--- this is what we need, run another node application here (backend) 
    },
    "configurations": {
        "production": {
            "devServerTarget": "backend:serve:production"
        }
    }
},

From e2e files, we can use the API URL which supertest allows.