Write Unit and E2E Tests for a NestJS Auth Module

This practice lesson doesn't introduce new testing concepts; it applies everything covered in this module, unit testing with mocks, and e2e testing with Supertest, to the complete auth module you built in Module 4, tying authentication and testing together into one concrete, hands-on exercise.

NestJS Auth Module Unit E2E Tests: Learning Objectives

• Write a unit test for an AuthService's signup logic, mocking bcrypt and a user repository.
• Write a unit test for AuthService's login logic, covering both success and invalid-credential paths.
• Write an e2e test covering the complete signup-then-login-then-protected-route flow.
• Write an e2e test verifying a protected route correctly rejects an unauthenticated request.
• Combine unit and e2e tests into one cohesive, well-organized test suite for an auth module.

NestJS Auth Module Unit E2E Tests: Key Terms and Definitions

• Auth module test suite: The combined set of unit and e2e tests covering an authentication module's signup, login, and route-protection behavior.
• jest.mock(): A Jest function used to automatically replace an entire imported module (like the bcrypt package) with a mock version throughout a test file.
• Success path / failure path: The two broad categories of test scenarios for authentication logic, one verifying correct behavior with valid input, one verifying correct rejection of invalid input.
• Test suite organization: Structuring related unit and e2e test files logically, commonly mirroring the source code's own module and file structure.

How NestJS Auth Module Unit E2E Tests Works: Detailed Explanation

Testing an authentication module thoroughly means covering it at two distinct levels, exactly matching the two test types this module has built up to. At the unit level, AuthService's signup() and login() methods should be tested in isolation, mocking both bcrypt (so tests don't perform genuinely slow, real password hashing) and the user repository (so tests don't depend on a real database), verifying the service's own logic: does signup() correctly call bcrypt.hash() and store only the hash, does login() correctly call bcrypt.compare() and throw UnauthorizedException on a mismatch, exactly the kind of internal correctness unit tests with mocks are best suited to verify quickly and cheaply.

Mocking bcrypt specifically is done using jest.mock('bcrypt'), which automatically replaces the entire bcrypt module with a mock version throughout the test file, after which individual methods like bcrypt.compare can have their specific mock behavior configured per test using (bcrypt.compare as jest.Mock).mockResolvedValue(true) or false, letting you test both the successful password match and mismatch paths without ever running real, deliberately slow bcrypt hashing during tests.

At the e2e level, the same auth module should be verified through real HTTP requests exactly as covered in this module's e2e lesson: a complete signup request, followed by a login request extracting a real JWT, followed by using that token to access a protected route, verifying the entire chain, hashing, storage, token issuance, guard verification, works correctly together exactly as a genuine user's experience would. A second, equally important e2e test verifies the negative case: attempting to access the protected route without any token at all correctly results in a 401 Unauthorized response, confirming the guard genuinely protects the route rather than accidentally allowing unauthenticated access through.

Organizing this complete test suite typically means an auth.service.spec.ts file (unit tests, focused on AuthService's own logic with mocked dependencies) living alongside the source code it tests, plus a separate test/auth.e2e-spec.ts file (e2e tests, verifying the complete, real request-response flow) in the dedicated e2e test folder, mirroring the same unit-versus-e2e file organization convention established throughout this module.

Interview-Friendly Explanation

A strong interview or viva answer for nestjs auth module unit e2e tests must go beyond a one-line definition. Interviewers evaluating backend developers reward answers that combine a precise definition, a clear working explanation, a real-world example, and a conclusion that highlights why it matters for shipping reliable production Node.js applications. Use the four-point framework below when answering under time pressure.

• Definition point: Auth module test suite: The combined set of unit and e2e tests covering an authentication module's signup, login, and route-protection behavior.
• Working point: Write a unit test for AuthService's login logic, covering both success and invalid-credential paths.
• Example point: Authentication modules are among the most heavily and carefully tested parts of virtually any production application, given the severe consequences of a security-related bug going unnoticed.
• Conclusion point: A genuinely well-tested auth module combines fast, precise unit tests with slower, maximally realistic e2e tests, not just one or the other.

How to Answer This in a Technical Interview

1. Give a two-to-three sentence definition using correct testing terminology (unit, integration, e2e).
2. Add one specific example drawn from a real backend scenario such as testing an auth flow or a CRUD API.
3. Mention a relevant trade-off, such as speed versus realism, since interviewers often probe this contrast.
4. Close with one benefit, limitation, or production consequence of getting this wrong.
5. Avoid vague answers like "it just makes sure the code works" — interviewers filter these out immediately.

Practical Scenario

Imagine you are shipping frequent changes to a production backend for a SaaS product, similar to systems used at companies like Razorpay, Freshworks, or Zomato. Every lesson in this module maps directly to a decision you will make to ship confidently: what to test, how to isolate it, and how to know your test suite is actually catching real problems before they reach users.

NestJS Auth Module Unit E2E Tests: Architecture and Flow Diagram

Visualize the complete two-level test coverage for the auth module:

[Unit Level: auth.service.spec.ts]
--> Mock bcrypt + mock UserRepository
--> Test: signup() correctly hashes password and stores user
--> Test: login() correctly verifies password and issues logic, or throws UnauthorizedException

[E2E Level: test/auth.e2e-spec.ts]
--> Real running application, real HTTP requests
--> Test: POST /auth/signup --> 201, POST /auth/login --> 200 + real JWT --> GET /profile with token --> 200
--> Test: GET /profile WITHOUT a token --> 401

What's Mocked vs What's Verified: Comparison Table

Test Level	What's Mocked	What's Verified
Unit (auth.service.spec.ts)	bcrypt, user repository	AuthService's own internal logic and correctness
E2E (test/auth.e2e-spec.ts)	Nothing — real app, real (test) requests	The complete, real signup/login/protected-route flow

NestJS Auth Module Unit E2E Tests: NestJS Code Example

// auth.service.spec.ts — unit tests with mocked bcrypt and repository
import { Test, TestingModule } from '@nestjs/testing';
import { UnauthorizedException } from '@nestjs/common';
import { getRepositoryToken } from '@nestjs/typeorm';
import { JwtService } from '@nestjs/jwt';
import * as bcrypt from 'bcrypt';
import { AuthService } from './auth.service';
import { User } from './user.entity';

jest.mock('bcrypt'); // replaces the entire bcrypt module with a mock throughout this file

describe('AuthService', () => {
  let service: AuthService;
  const mockUserRepository = { findOne: jest.fn(), create: jest.fn(), save: jest.fn() };
  const mockJwtService = { signAsync: jest.fn().mockResolvedValue('fake-jwt-token') };

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      providers: [
        AuthService,
        { provide: getRepositoryToken(User), useValue: mockUserRepository },
        { provide: JwtService, useValue: mockJwtService },
      ],
    }).compile();

    service = module.get<AuthService>(AuthService);
    jest.clearAllMocks();
  });

  describe('login', () => {
    it('should return an access token when credentials are valid', async () => {
      mockUserRepository.findOne.mockResolvedValue({ id: 1, email: 'asha@example.com', passwordHash: 'hashed' });
      (bcrypt.compare as jest.Mock).mockResolvedValue(true); // simulate a correct password

      const result = await service.login({ email: 'asha@example.com', password: 'correct' });

      expect(result.accessToken).toBe('fake-jwt-token');
    });

    it('should throw UnauthorizedException when the password is incorrect', async () => {
      mockUserRepository.findOne.mockResolvedValue({ id: 1, email: 'asha@example.com', passwordHash: 'hashed' });
      (bcrypt.compare as jest.Mock).mockResolvedValue(false); // simulate a wrong password

      await expect(
        service.login({ email: 'asha@example.com', password: 'wrong' }),
      ).rejects.toThrow(UnauthorizedException);
    });
  });
});

// test/auth.e2e-spec.ts — e2e tests covering the complete real flow
import { Test, TestingModule } from '@nestjs/testing';
import { INestApplication } from '@nestjs/common';
import * as request from 'supertest';
import { AppModule } from './../src/app.module';

describe('Auth Module (e2e)', () => {
  let app: INestApplication;

  beforeAll(async () => {
    const moduleFixture: TestingModule = await Test.createTestingModule({
      imports: [AppModule],
    }).compile();
    app = moduleFixture.createNestApplication();
    await app.init();
  });

  afterAll(async () => app.close());

  it('should complete the full signup, login, and protected-route flow', async () => {
    await request(app.getHttpServer())
      .post('/auth/signup')
      .send({ name: 'Test User', email: 'test.user@example.com', password: 'SecurePass123' })
      .expect(201);

    const loginRes = await request(app.getHttpServer())
      .post('/auth/login')
      .send({ email: 'test.user@example.com', password: 'SecurePass123' })
      .expect(200);

    return request(app.getHttpServer())
      .get('/profile')
      .set('Authorization', `Bearer ${loginRes.body.accessToken}`)
      .expect(200);
  });

  it('should reject an unauthenticated request to a protected route', () => {
    return request(app.getHttpServer()).get('/profile').expect(401);
  });
});

The unit test file uses jest.mock('bcrypt') to automatically mock the entire bcrypt module, then configures (bcrypt.compare as jest.Mock).mockResolvedValue() differently across the two login tests, true for the success case and false for the incorrect-password case, alongside a mocked user repository and JwtService, verifying AuthService.login()'s own logic in both scenarios without any real password hashing or database queries. The e2e test file, by contrast, imports the entire real AppModule and sends genuine HTTP requests through the full application, verifying the complete signup-login-protected-route chain works correctly together with real (if test-specific) data, and separately confirming that an unauthenticated request to the same protected route is correctly rejected with 401. Together, these two files provide layered confidence: fast, precise unit tests confirming AuthService's internal logic is correct, and slower, but maximally realistic, e2e tests confirming the entire real-world user flow genuinely works end to end.

Real-World NestJS Auth Module Unit E2E Tests Industry Examples

• Authentication modules are among the most heavily and carefully tested parts of virtually any production application, given the severe consequences of a security-related bug going unnoticed.
• Teams commonly require both unit and e2e test coverage specifically for auth-related code as a non-negotiable code review standard, given how critical correct authentication behavior is.
• Security audits and penetration testing engagements often specifically check for the existence of e2e tests verifying that protected routes genuinely reject unauthenticated and improperly authenticated requests.
• Bug reports involving authentication (like a protected route accidentally becoming accessible without a valid token) are almost always followed by adding a new, permanent e2e test reproducing that exact scenario to prevent regression.

NestJS Auth Module Unit E2E Tests Interview Questions and Answers

Q1. How would you unit test an AuthService's login method without performing real, slow bcrypt hashing?

Short answer: You would use jest.mock('bcrypt') to automatically replace the entire bcrypt module with a mock, then configure (bcrypt.compare as jest.Mock).mockResolvedValue(true or false) differently across separate test cases to simulate both a correct and an incorrect password, verifying AuthService's response in each scenario without any real, deliberately slow cryptographic hashing actually occurring during the test.

Detailed explanation: Testing an authentication module thoroughly means covering it at two distinct levels, exactly matching the two test types this module has built up to. At the unit level, AuthService's signup() and login() methods should be tested in isolation, mocking both bcrypt (so tests don't perform genuinely slow, real password hashing) and the user repository (so tests don't depend on a real database), verifying the service's own logic: does signup() correctly call bcrypt.hash() and store only the hash, does login() correctly call bcrypt.compare() and throw UnauthorizedException on a mismatch, exactly the kind of internal correctness unit tests with mocks are best suited to verify quickly and cheaply. Mocking bcrypt specifically is done using jest.mock('bcrypt'), which automatically replaces the entire bcrypt module with a mock version throughout the test file, after which individual methods like bcrypt.compare can have their specific mock behavior configured per test using (bcrypt.compare as jest.Mock).mockResolvedValue(true) or false, letting you test both the successful password match and mismatch paths without ever running real, deliberately slow bcrypt hashing during tests. At the e2e level, the same auth module should be verified through real HTTP requests exactly as covered in this module's e2e lesson: a complete signup request, followed by a login request extracting a real JWT, followed by using that token to access a protected route, verifying the entire chain, hashing, storage, token issuance, guard verification, works correctly together exactly as a genuine user's experience would. A second, equally important e2e test verifies the negative case: attempting to access the protected route without any token at all correctly results in a 401 Unauthorized response, confirming the guard genuinely protects the route rather than accidentally allowing unauthenticated access through. Organizing this complete test suite typically means an auth.service.spec.ts file (unit tests, focused on AuthService's own logic with mocked dependencies) living alongside the source code it tests, plus a separate test/auth.e2e-spec.ts file (e2e tests, verifying the complete, real request-response flow) in the dedicated e2e test folder, mirroring the same unit-versus-e2e file organization convention established throughout this module.

Practical example: Authentication modules are among the most heavily and carefully tested parts of virtually any production application, given the severe consequences of a security-related bug going unnoticed.

Interview tip: jest.mock('bcrypt') mocks the entire module; (bcrypt.compare as jest.Mock).mockResolvedValue() configures its behavior per test.

Revision hook: A genuinely well-tested auth module combines fast, precise unit tests with slower, maximally realistic e2e tests, not just one or the other.

Q2. What is the value of writing an e2e test for the complete signup-login-protected-route flow, given that unit tests already cover AuthService's logic?

Short answer: While unit tests verify AuthService's own internal logic in isolation, an e2e test verifies that every real, wired-together piece, password hashing, database storage, JWT signing, the Passport strategy, and the guard, genuinely works correctly together exactly as a real user's actual experience would, catching integration issues between these pieces that isolated unit tests, by design, cannot detect.

Detailed explanation: The unit test file uses jest.mock('bcrypt') to automatically mock the entire bcrypt module, then configures (bcrypt.compare as jest.Mock).mockResolvedValue() differently across the two login tests, true for the success case and false for the incorrect-password case, alongside a mocked user repository and JwtService, verifying AuthService.login()'s own logic in both scenarios without any real password hashing or database queries. The e2e test file, by contrast, imports the entire real AppModule and sends genuine HTTP requests through the full application, verifying the complete signup-login-protected-route chain works correctly together with real (if test-specific) data, and separately confirming that an unauthenticated request to the same protected route is correctly rejected with 401. Together, these two files provide layered confidence: fast, precise unit tests confirming AuthService's internal logic is correct, and slower, but maximally realistic, e2e tests confirming the entire real-world user flow genuinely works end to end.

Practical example: Teams commonly require both unit and e2e test coverage specifically for auth-related code as a non-negotiable code review standard, given how critical correct authentication behavior is.

Interview tip: Unit tests for AuthService should cover both success (valid credentials) and failure (invalid credentials) paths.

Revision hook: Mocking bcrypt and the repository lets AuthService's own logic be tested quickly and repeatedly without real hashing or database overhead.

Q3. Why is it important to also test the failure path, like an incorrect password or a missing token, not just the success path?

Short answer: Verifying correct rejection behavior is just as critical as verifying correct acceptance, especially for authentication, since a bug allowing incorrect credentials to succeed, or allowing an unauthenticated request through, represents a serious security vulnerability that testing only the success path would never catch.

Detailed explanation: Thoroughly testing a NestJS authentication module means combining both test types covered throughout this module. Unit tests for AuthService, using jest.mock('bcrypt') and mocked repository/JwtService dependencies, verify the service's own internal logic in isolation, covering both a successful login with valid credentials and a correctly rejected login with an invalid password, all without any real, slow cryptographic hashing or database queries. E2e tests, importing the complete real AppModule and using Supertest to send genuine HTTP requests, verify the entire real-world flow works correctly together: a full signup, followed by a login extracting an actual JWT, followed by using that token to successfully access a protected route, alongside a separate test confirming an unauthenticated request to that same route is correctly rejected with a 401. Together, these complementary unit and e2e tests provide the layered confidence any security-critical authentication module genuinely requires before shipping to production.

Practical example: Security audits and penetration testing engagements often specifically check for the existence of e2e tests verifying that protected routes genuinely reject unauthenticated and improperly authenticated requests.

Interview tip: E2e tests should verify both the full successful flow (signup → login → protected route) and the rejection case (no token → 401).

Revision hook: Testing both success and failure paths is non-negotiable for security-critical logic like authentication.

Q4. How would you organize unit and e2e tests for an auth module within a NestJS project's file structure?

Short answer: Unit tests, like auth.service.spec.ts, typically live alongside the source file they test within the module's own folder, following NestJS's standard convention, while e2e tests, like auth.e2e-spec.ts, live in the dedicated top-level test/ folder, keeping the faster unit test suite and the slower, more comprehensive e2e suite clearly separated.

Detailed explanation: Testing an authentication module thoroughly means covering it at two distinct levels, exactly matching the two test types this module has built up to. At the unit level, AuthService's signup() and login() methods should be tested in isolation, mocking both bcrypt (so tests don't perform genuinely slow, real password hashing) and the user repository (so tests don't depend on a real database), verifying the service's own logic: does signup() correctly call bcrypt.hash() and store only the hash, does login() correctly call bcrypt.compare() and throw UnauthorizedException on a mismatch, exactly the kind of internal correctness unit tests with mocks are best suited to verify quickly and cheaply. Mocking bcrypt specifically is done using jest.mock('bcrypt'), which automatically replaces the entire bcrypt module with a mock version throughout the test file, after which individual methods like bcrypt.compare can have their specific mock behavior configured per test using (bcrypt.compare as jest.Mock).mockResolvedValue(true) or false, letting you test both the successful password match and mismatch paths without ever running real, deliberately slow bcrypt hashing during tests. At the e2e level, the same auth module should be verified through real HTTP requests exactly as covered in this module's e2e lesson: a complete signup request, followed by a login request extracting a real JWT, followed by using that token to access a protected route, verifying the entire chain, hashing, storage, token issuance, guard verification, works correctly together exactly as a genuine user's experience would. A second, equally important e2e test verifies the negative case: attempting to access the protected route without any token at all correctly results in a 401 Unauthorized response, confirming the guard genuinely protects the route rather than accidentally allowing unauthenticated access through. Organizing this complete test suite typically means an auth.service.spec.ts file (unit tests, focused on AuthService's own logic with mocked dependencies) living alongside the source code it tests, plus a separate test/auth.e2e-spec.ts file (e2e tests, verifying the complete, real request-response flow) in the dedicated e2e test folder, mirroring the same unit-versus-e2e file organization convention established throughout this module.

Practical example: Bug reports involving authentication (like a protected route accidentally becoming accessible without a valid token) are almost always followed by adding a new, permanent e2e test reproducing that exact scenario to prevent regression.

Interview tip: auth.service.spec.ts (unit) lives with the source; auth.e2e-spec.ts (e2e) lives in the dedicated test/ folder.

Revision hook: This complete testing pattern, applied to Module 4's auth module, is directly reusable for any other feature's own unit and e2e test suite.

NestJS Auth Module Unit E2E Tests MCQs and Practice Questions

1. Which Jest function automatically replaces an entire imported module, like bcrypt, with a mock version?

1. jest.fn()
2. jest.mock()
3. jest.spyOn()
4. jest.clearAllMocks()

Answer: B. jest.mock()

Explanation: jest.mock('moduleName') automatically replaces the entire specified module with an auto-mocked version throughout the test file, allowing individual mocked methods to then be configured with specific return values per test.

Concept link: jest.mock('bcrypt') mocks the entire module; (bcrypt.compare as jest.Mock).mockResolvedValue() configures its behavior per test.

Why this matters: A genuinely well-tested auth module combines fast, precise unit tests with slower, maximally realistic e2e tests, not just one or the other.

2. In a unit test for AuthService.login(), what should be verified for an incorrect password?

1. That the method returns undefined silently
2. That the method throws an UnauthorizedException
3. That a real database error occurs
4. That the test suite crashes

Answer: B. That the method throws an UnauthorizedException

Explanation: A correctly implemented login() method should explicitly throw an UnauthorizedException when the submitted password doesn't match, and the unit test should assert exactly this behavior for the incorrect-password scenario.

Concept link: Unit tests for AuthService should cover both success (valid credentials) and failure (invalid credentials) paths.

Why this matters: Mocking bcrypt and the repository lets AuthService's own logic be tested quickly and repeatedly without real hashing or database overhead.

3. What should an e2e test verify about a protected route when no Authorization token is provided?

1. That it returns 200 OK anyway
2. That it returns a 401 Unauthorized response
3. That the server crashes
4. That it silently redirects to the login page

Answer: B. That it returns a 401 Unauthorized response

Explanation: A correctly protected route should reject requests lacking valid authentication with a 401 Unauthorized status, and an e2e test should explicitly verify this rejection behavior for an unauthenticated request.

Concept link: E2e tests should verify both the full successful flow (signup → login → protected route) and the rejection case (no token → 401).

Why this matters: Testing both success and failure paths is non-negotiable for security-critical logic like authentication.

4. Why does testing an authentication module typically involve both unit and e2e tests, rather than just one type?

1. Because NestJS requires both by default
2. Because unit tests verify isolated logic quickly while e2e tests verify the complete, real, wired-together flow works correctly
3. Because e2e tests alone are always sufficient
4. Because unit tests cannot test services at all

Answer: B. Because unit tests verify isolated logic quickly while e2e tests verify the complete, real, wired-together flow works correctly

Explanation: Unit and e2e tests serve complementary purposes: unit tests quickly verify a service's own internal correctness with mocked dependencies, while e2e tests confirm every real piece genuinely works together exactly as a real user would experience, providing layered confidence.

Concept link: auth.service.spec.ts (unit) lives with the source; auth.e2e-spec.ts (e2e) lives in the dedicated test/ folder.

Why this matters: This complete testing pattern, applied to Module 4's auth module, is directly reusable for any other feature's own unit and e2e test suite.

Common NestJS Auth Module Unit E2E Tests Mistakes to Avoid

• Testing only the success path (valid credentials) for login logic, without also verifying correct rejection behavior for invalid credentials.
• Forgetting to reset mocks between test cases, causing bcrypt.compare's configured mock value from one test to incorrectly bleed into another.
• Relying solely on unit tests for an auth module without any e2e coverage, missing potential integration issues between real, wired-together components.
• Not testing the negative e2e case (an unauthenticated request to a protected route), leaving a potentially serious security gap unverified.

NestJS Auth Module Unit E2E Tests: Interview Notes and Exam Tips

• jest.mock('bcrypt') mocks the entire module; (bcrypt.compare as jest.Mock).mockResolvedValue() configures its behavior per test.
• Unit tests for AuthService should cover both success (valid credentials) and failure (invalid credentials) paths.
• E2e tests should verify both the full successful flow (signup → login → protected route) and the rejection case (no token → 401).
• auth.service.spec.ts (unit) lives with the source; auth.e2e-spec.ts (e2e) lives in the dedicated test/ folder.

Key NestJS Auth Module Unit E2E Tests Takeaways

• A genuinely well-tested auth module combines fast, precise unit tests with slower, maximally realistic e2e tests, not just one or the other.
• Mocking bcrypt and the repository lets AuthService's own logic be tested quickly and repeatedly without real hashing or database overhead.
• Testing both success and failure paths is non-negotiable for security-critical logic like authentication.
• This complete testing pattern, applied to Module 4's auth module, is directly reusable for any other feature's own unit and e2e test suite.

NestJS Auth Module Unit E2E Tests: Summary

Thoroughly testing a NestJS authentication module means combining both test types covered throughout this module. Unit tests for AuthService, using jest.mock('bcrypt') and mocked repository/JwtService dependencies, verify the service's own internal logic in isolation, covering both a successful login with valid credentials and a correctly rejected login with an invalid password, all without any real, slow cryptographic hashing or database queries. E2e tests, importing the complete real AppModule and using Supertest to send genuine HTTP requests, verify the entire real-world flow works correctly together: a full signup, followed by a login extracting an actual JWT, followed by using that token to successfully access a protected route, alongside a separate test confirming an unauthenticated request to that same route is correctly rejected with a 401. Together, these complementary unit and e2e tests provide the layered confidence any security-critical authentication module genuinely requires before shipping to production.