Simplificando Testes no NestJS com Injeção de Valores

This content originally appeared on DEV Community and was authored by Tadeu Barbosa

Quando trabalhamos com NestJS, é muito comum ver serviços injetando o ConfigService diretamente. Isso funciona bem, mas pode tornar os testes mais complexos e acoplar o código a detalhes de configuração.

Vamos comigo enquanto escuto uma playlist de techno no youtube.

Neste artigo, vou mostrar uma abordagem simples para desacoplar suas classes e facilitar os testes, injetando valores primitivos prontos via módulo.

O problema: acoplamento ao ConfigService

Um serviço de criação de contato que valida a data mínima poderia ser escrito assim:

@Injectable()
export class CreateContactService {
  constructor(private readonly config: ConfigService) {}

  execute(name: string, birthDate: Date) {
    const minDate = this.config.get<Date>('CONTACT_MIN_DATE');
    if (birthDate < minDate) {
      throw new Error('Data inválida');
    }
    return { name, birthDate };
  }
}

Funciona, mas agora qualquer teste precisa mockar o ConfigService.Isso gera fricção desnecessária.

A solução: injetar valores prontos via módulo

Podemos mover a responsabilidade para o módulo:

@Injectable()
export class CreateContactService {
  constructor(private readonly minDate: Date) {}

  execute(name: string, birthDate: Date) {
    if (birthDate < this.minDate) {
      throw new Error('Data inválida');
    }
    return { name, birthDate };
  }
}

E no módulo:

@Module({
  providers: [
    {
      provide: CreateContactService,
      useFactory: (config: ConfigService) => {
        return new CreateContactService(
          config.get<Date>('CONTACT_MIN_DATE'),
        );
      },
      inject: [ConfigService],
    },
  ],
  exports: [CreateContactService],
})
export class ContactModule {}

Por que é melhor?

• Classes mais puras – não sabem de onde o valor veio

• Testes mais simples – basta instanciar new CreateContactService(new Date(‘2000-01-01’))

• Configuração centralizada – módulos realmente controlam dependências

• Alinhado a SOLID – especialmente Dependency Inversion Principle

Conclusão

Essa pequena mudança de perspectiva (deixar o módulo resolver configs e injetar valores prontos) pode simplificar bastante seus testes e deixar seu código mais limpo.

Injeção de dependência não é só sobre classes complexas: até valores primitivos podem (e devem) ser tratados como dependências.

E você, já aplica esse padrão em seus projetos NestJS?

This content originally appeared on DEV Community and was authored by Tadeu Barbosa