Auto-Exposing dependencies

[QozbroQqn]

As mentioned here I think an auto exposing feature would be nice. I already have implemented such a feature but its adapted to our needs. Also its quite new and we havent used it much. For others: Use carefully (or not at all if you dont know what this is doing or why you might need it).

import 'reflect-metadata';
import type { Type } from '@nestjs/common';

import { PrismaService } from '#src/modules/prisma/services/prisma.service.js';
import { type SociableTestBedBuilder, TestBed } from '@suites/unit';
import { ClsService as NestClsService } from 'nestjs-cls';

/**
 * Builds a sociable TestBed with transitive dependencies exposed up to boundaries.
 * Defaults:
 * - PrismaService is a stop boundary (kept mocked but reachable)
 * - NestClsService is excluded (kept mocked to avoid AsyncLocalStorage requirements)
 *
 * You can explicitly include either to override these defaults.
 */
export function sociableAutoExpose<T>(
  sut: Type<T>,
  options?: {
    exclude?: Type<unknown>[];
    include?: Type<unknown>[];
    stopAt?: Type<unknown>[];
  },
): SociableTestBedBuilder<T> {
  const defaultStopAt = new Set<Type<unknown>>([PrismaService]);
  const defaultExclude = new Set<Type<unknown>>([NestClsService]);

  const include = new Set<Type<unknown>>(options?.include ?? []);
  if (include.has(PrismaService)) defaultStopAt.delete(PrismaService);
  if (include.has(NestClsService)) defaultExclude.delete(NestClsService);

  const mergedStopAt = new Set<Type<unknown>>([
    ...(options?.stopAt ?? []),
    ...defaultStopAt,
  ]);
  const mergedExclude = new Set<Type<unknown>>([
    ...(options?.exclude ?? []),
    ...defaultExclude,
  ]);

  const toExpose = collectDepsTransitively(sut, {
    exclude: Array.from(mergedExclude),
    stopAt: Array.from(mergedStopAt),
  });

  for (const inc of include) {
    if (!toExpose.includes(inc)) toExpose.push(inc);
  }

  if (toExpose.length === 0) {
    throw new Error(
      `sociableAutoExpose: No dependencies to expose were discovered for ${sut.name}. ` +
        `Provide 'include' with at least one dependency, or adjust 'stopAt'/'exclude'.`,
    );
  }

  // Initial expose() needed! TS doesnt infer SociableTestBedBuilder<T> otherwise
  let builder = TestBed.sociable(sut).expose(toExpose[0]);
  for (let i = 1; i < toExpose.length; i++) {
    builder = builder.expose(toExpose[i]);
  }

  return builder;
}

/**
 * Collect constructor dependency classes transitively using design:paramtypes metadata.
 * Traversal stops when encountering any class in the stopAt set (these are boundaries to mock).
 * The SUT itself is not included in the returned list.
 */
function collectDepsTransitively<T>(
  root: Type<T>,
  options?: {
    exclude?: Type<unknown>[];
    stopAt?: Type<unknown>[];
  },
): Type<unknown>[] {
  const stopAt = new Set<Type<unknown>>(options?.stopAt ?? []);
  const exclude = new Set<Type<unknown>>(options?.exclude ?? []);
  const traversed = new Set<Type<unknown>>();
  const toTraverse: Type<unknown>[] = [root];

  while (toTraverse.length) {
    const currentType = toTraverse.pop()!;
    if (traversed.has(currentType)) continue;
    traversed.add(currentType);

    const designParamTypes: unknown = Reflect.getMetadata(
      'design:paramtypes',
      currentType,
    );
    const paramTypes = (designParamTypes ?? []) as Type<unknown>[];

    for (const dependencyType of paramTypes) {
      if (typeof dependencyType !== 'function') continue;
      if (stopAt.has(dependencyType)) continue;
      if (exclude.has(dependencyType)) continue;
      toTraverse.push(dependencyType);
    }
  }

  traversed.delete(root);
  for (const ex of exclude) {
    traversed.delete(ex);
  }

  return Array.from(traversed);
}

Usage:

const mockSociable = async () => {
  const { unit, unitRef } = await sociableAutoExpose(CommentResolver).compile();

  return {
    nestClsService: unitRefMock(unitRef, NestClsService), // <-- unitRef.get(NestClsService)
    prismaService: unitRefMock(unitRef, PrismaService), // <-- unitRef.get(PrismaService)
    resolver: unit,
  };
};

Yes with this we come really close to an integration test. But in our test setup we only test integration of modules and just the results. We dont have integration tests for services, resolvers, controllers, repositories, ... Our integration tests can be seen as a lightweight e2e test for a module testing only that module isolated. Tests always call resolver/controller function.

[omermorad]

Tracked in issue #820. Following progress there.