# Testing

## What it is responsible for

The Testing subsystem manages the testing package’s named work-entry surface through `TestingLogger`, `MockFactory`, and `OverrideByFactoryOptions`. Its documented material also directs developers to the Nest guide at docs.nestjs.com, the official Discord channel for questions and support, and the Issue Reporting Checklist before an issue is opened. The package’s responsibility is bounded by the available evidence: the listed symbols identify logging, mock-factory, and factory-override-option concerns, while the supplied comments do not describe their detailed behavior.

## What it refuses

It refuses to continue when an internal [core](subsystem-packages-core) module reference is absent: “Expected to have internal core module reference at this point.” The stated condition is `!internalCoreModule`; this is a hard rejection, not a fallback path described by the evidence.

## What it needs, and who needs it

Testing depends on the [Common](subsystem-packages-common) and Core subsystems. In particular, the refusal condition shows that the relevant path needs `internalCoreModule` at that point. No subsystem is listed as depending on Testing. Therefore the evidence names no consumer-side subsystem and identifies no specific downstream behavior that breaks without Testing; only its own path is known to reject the missing internal-core reference.

## Notable members

`TestingLogger` is a work-entry symbol and carries the package’s explicitly named logger role. `MockFactory` is another work-entry symbol; its name identifies the factory as mock-oriented, but the evidence does not state creation rules, lifetime, or output. `OverrideByFactoryOptions` is the third work-entry symbol and represents factory-based override options. Together, these symbols mark the visible testing-facing path, while the source material does not establish a call sequence among them. No documented member-level dependency or implementation contract is explicitly stated here.

41 entities in `packages/testing`. Nothing else in this repository depends on it.

## What it is made of

Its 41 entities sit in 11 files under `packages/testing`: 29 doc comments, 6 classes, 3 interfaces, 2 type aliases and 1 more.
`testing-module.builder.ts` holds 2 of them — more than any other file here.
`TestingModuleBuilder` declares 9 methods, the widest surface here.

## Where work enters

- [`TestingLogger`](class-testinglogger) — `packages/testing/services/testing-logger.service.ts`:6
- `Readme.md` — `packages/testing/Readme.md`:1
- [`MockFactory`](type-mockfactory) — `packages/testing/interfaces/mock-factory.ts`:3
- [`OverrideByFactoryOptions`](interface-overridebyfactoryoptions) — `packages/testing/interfaces/override-by-factory-options.interface.ts`:4

## How it refuses and fails

2 of its components record a refusal or a failure handler.
All 2 of them refuse work outright, under a condition written into the component itself.
Their `catch` blocks handle a failure that already happened in 2 places.

## Boundaries

It depends on `Common`, `Core`, and on nothing else in this repository.