Simplificando Testes no NestJS com Injeção de Valores

  • Thread starter Thread starter Tadeu Barbosa
  • Start date Start date
T

Tadeu Barbosa

Guest
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:


Code:
@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:


Code:
@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:


Code:
@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?

Continue reading...
 


Join 𝕋𝕄𝕋 on Telegram
Channel PREVIEW:
Back
Top