NestJS Quality Control & Assurance 4 — Questions and Answers
Question 1: Which NestJS-specific Jest preset should be configured in jest.config.ts for a standard NestJS project?
- ts-jest (Correct answer)
- @nestjs/testing/jest-preset
- babel-jest
- jest-circus
Correct answer: ts-jest
ts-jest transpiles TypeScript and is the standard preset used by the NestJS CLI-generated jest.config.js.
Question 2: What is a primary advantage of using `jest.mock()` at the module level instead of `jest.spyOn()` inside individual tests?
- It allows partial mocking of a module's exports
- It hoists the mock before imports, ensuring all imports receive the mocked version (Correct answer)
- It automatically restores the original after each test
- It only works with default exports
Correct answer: It hoists the mock before imports, ensuring all imports receive the mocked version
jest.mock() is hoisted to the top of the file by Babel/ts-jest, so even top-level import statements receive the mock.
Question 3: When testing a NestJS GraphQL resolver, which method of the TestingModule allows you to invoke the resolver method directly without going through the GraphQL layer?
- module.get(Resolver).methodName() (Correct answer)
- module.graphql('query ...')
- module.execute(document)
- module.resolve('Query.fieldName')
Correct answer: module.get(Resolver).methodName()
Resolvers are plain providers; retrieving them with module.get() and calling the method directly is the simplest unit-test approach.
Question 4: Which approach correctly tests a NestJS ExceptionFilter without starting the full HTTP server?
- Call filter.catch() directly with mocked ArgumentsHost and HttpException (Correct answer)
- Use Supertest to trigger a 500 response
- Override the ExceptionFilter in the testing module
- Disable the filter with app.useGlobalFilters() before the test
Correct answer: Call filter.catch() directly with mocked ArgumentsHost and HttpException
ExceptionFilters are plain classes; instantiating the filter and calling catch() with mock ArgumentsHost objects lets you unit-test the error response logic.
Question 5: What does the `--coverage` flag in `jest` produce that is useful for NestJS CI pipelines?
- A list of uncovered route handlers
- A code coverage report showing statement, branch, function, and line percentages (Correct answer)
- A performance benchmark for each test
- A diff of changed test files
Correct answer: A code coverage report showing statement, branch, function, and line percentages
--coverage instruments the code with Istanbul and outputs HTML/LCOV reports with line-level coverage data.
Question 6: In NestJS, how do you test that a custom Pipe correctly throws a BadRequestException for invalid input?
- Wrap the transform() call in expect(() => pipe.transform(value, metadata)).toThrow(BadRequestException) (Correct answer)
- Mock the BadRequestException constructor
- Use Supertest to send invalid data and assert status 400
- Override the pipe with jest.fn()
Correct answer: Wrap the transform() call in expect(() => pipe.transform(value, metadata)).toThrow(BadRequestException)
Pipes are plain classes; calling transform() synchronously and wrapping it with Jest's toThrow() matcher is the direct unit-test approach.
Question 7: Which Jest option in a NestJS project causes tests to re-run automatically when source files change?
- jest --daemon
- jest --watch (Correct answer)
- jest --continuous
- jest --live
Correct answer: jest --watch
--watch mode monitors file system changes and reruns only affected tests, speeding up the TDD feedback loop.
Which NestJS-specific Jest preset should be configured in jest.config.ts for a standard NestJS project?