Conversation
WalkthroughAdiciona mocks de email (usuário, empresa, vaga, opções), uma suíte de testes unitários para MailService; ajusta docker-compose (serviço postgres e mailhog), corrige campo JSON em CompaniesEntity (instagran→instagram), ajusta assunto em sendCompanyCreationConfirmation, altera import e formatação em alguns arquivos e atualiza assertivas de testes para mensagens em português. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Tester as Teste
participant MS as MailService
participant Mailer as MailerService (mock)
rect rgba(200,220,255,0.25)
note over Tester,MS: Confirmação/recuperação de usuário
Tester->>MS: sendUserConfirmation(user)
alt com token
MS->>Mailer: sendMail({ template: "./send", context: { url, type: "USER" } })
else sem token
MS->>Mailer: sendMail({ template: "./passwordupdate", context: { url: null } })
end
Mailer-->>MS: resolve / rejeita
end
rect rgba(200,255,220,0.25)
note over Tester,MS: Confirmação/recuperação de empresa
Tester->>MS: sendCompanyConfirmation(company)
alt com token
MS->>Mailer: sendMail({ template: "./send", context: { url, type: "COMPANY" } })
else sem token
MS->>Mailer: sendMail({ template: "./passwordupdate", context: { companyName } })
end
Mailer-->>MS: resolve / rejeita
end
rect rgba(255,240,200,0.25)
note over Tester,MS: Alerta de vagas
Tester->>MS: sendJobAlerts({ email, jobs[] })
MS->>Mailer: sendMail({ template: "./jobsAlert", context: { jobs[] } })
Mailer-->>MS: resolve / rejeita
end
rect rgba(235,235,235,0.5)
note over Tester,MS: Envio genérico
Tester->>MS: sendMail(options)
MS->>Mailer: sendMail(options)
Mailer-->>MS: resolve / rejeita
end
Estimated code review effort🎯 3 (Moderado) | ⏱️ ~30 minutes Pontos que merecem atenção extra:
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (13)
test/mocks/mail/mail-options.mock.ts (2)
3-12: Mocks OK, mas considere tipar o shape e permitir overridesEstrutura estável para os testes. Para aumentar reuso e evitar “drift” caso o serviço mude, recomendo tipar o objeto e aceitar overrides.
-export const mailOptionsMock = () => ({ +type TestMailOptions = { + email: string; + subject: string; + template: string; + context: { + name: string; + message?: string; + url?: string; + }; +}; + +export const mailOptionsMock = (overrides: Partial<TestMailOptions> = {}): TestMailOptions => ({ subject: 'Teste de Email', template: './test-template', context: { name: 'Usuario Teste', message: 'Esta é uma mensagem de teste', url: 'https://example.com/test', }, email: 'test@example.com', -}); + ...overrides, +});
14-17: Mock de alertas de vagas: habilite overrides ou remova se não for usadoAtualmente não é utilizado neste spec. Se for mantido para uso futuro, aceite overrides para facilitar cenários diferentes; caso contrário, considere remover para reduzir ruído.
-export const jobAlertMailOptionsMock = () => ({ - email: 'candidate@example.com', - jobs: jobMailListMock(), -}); +export const jobAlertMailOptionsMock = ( + overrides: Partial<{ email: string; jobs: ReturnType<typeof jobMailListMock> }> = {}, +) => ({ + email: 'candidate@example.com', + jobs: jobMailListMock(), + ...overrides, +});test/mocks/mail/user-mail.mock.ts (3)
3-25: Reduza duplicação e aumente reuso com overrides no factoryO padrão de factory com overrides simplifica a criação de variações (evita espalhar spreads em cada mock “sem token”).
-export const userMailMock = (): UsersEntity => ({ +export const userMailMock = (overrides: Partial<UsersEntity> = {}): UsersEntity => ({ id: '729c7919-583c-40a5-b0ca-137e282345d4', name: 'Test User', email: 'user@example.com', password: 'hashedPassword123', recoverPasswordToken: 'recover-token-123', mailConfirm: false, type: 'USER', policies: true, created_at: new Date('2023-01-01T00:00:00.000Z'), updated_at: new Date('2023-01-01T00:00:00.000Z'), ip: '127.0.0.1', mainPhone: '11999999999', phone: '1133333333', city: 'São Paulo', state: 'SP', profile: null, profileKey: null, personalData: null, curriculums: [], applications: [], candidacies: [], -}); + ...overrides, +});
27-31: Aproveite o factory com overrides no mock “sem token”Com o factory parametrizável, o mock “sem token” fica mais explícito e sucinto.
-export const userMailWithoutTokenMock = (): UsersEntity => ({ - ...userMailMock(), - recoverPasswordToken: null, - mailConfirm: true, -}); +export const userMailWithoutTokenMock = (): UsersEntity => + userMailMock({ recoverPasswordToken: null, mailConfirm: true });
12-13: Atenção à consistência de nomenclatura entre entidadesVerificamos que:
- Em
UsersEntity(src/database/entities/users.entity.ts linhas 79–83), os campos estão definidos comocreated_ateupdated_at.- Em
JobsEntity(src/database/entities/jobs.entity.ts linhas 130–134), os campos correspondentes usamcreatedAteupdatedAt.Os mocks em
test/mocks/mail/user-mail.mock.ts(linhas 12–13) espelham corretamente o que há emUsersEntity. Porém, manter duas convenções diferentes no mesmo projeto pode causar confusão ou erros de digitação/falha de type-check em outros trechos do código.Para padronizar, vocês podem escolher uma das abordagens:
Manter camelCase no código-fonte e mapear para snake_case no banco
• EmUsersEntity, renomear:@CreateDateColumn({ name: 'created_at' }) createdAt: Date; @UpdateDateColumn({ name: 'updated_at', update: true }) updatedAt: Date;• Atualizar os mocks em
test/mocks/mail/user-mail.mock.tsde acordo (usarcreatedAt/updatedAt).Manter snake_case em todas as entidades
• EmJobsEntity, ajustar para:@CreateDateColumn({ name: 'created_at' }) created_at: Date; @UpdateDateColumn({ name: 'updated_at', update: true }) updated_at: Date;• Atualizar quaisquer usos de camelCase em DTOs, serviços ou testes referentes a Jobs.
Escolher uma única convenção e aplicar em todas as entidades e mocks ajudará a evitar surpresas de tipo no futuro.
test/mocks/mail/company-mail.mock.ts (1)
3-26: Parametrize o factory e derive a variante “sem token”Mesmo racional dos demais mocks: reduz duplicação e facilita futuros cenários.
-export const companyMailMock = (): CompaniesEntity => ({ +export const companyMailMock = (overrides: Partial<CompaniesEntity> = {}): CompaniesEntity => ({ id: '123e4567-e89b-12d3-a456-426614174000', companyName: 'Test Company LTDA', email: 'company@example.com', cnpj: '12345678000199', password: 'hashedPassword123', recoverPasswordToken: 'company-recover-token-456', mailConfirm: false, created_at: new Date('2023-01-01T00:00:00.000Z'), updated_at: new Date('2023-01-01T00:00:00.000Z'), companyType: 'Tecnologia', companySize: 'SMALL_SIZE', uf: 'SP', otherSite: { - instagran: 'https://instagram.com/testcompany', + instagram: 'https://instagram.com/testcompany', linkedin: 'https://linkedin.com/company/testcompany', twitter: 'https://twitter.com/testcompany', }, companySite: 'https://testcompany.com.br', description: 'Empresa de tecnologia focada em soluções inovadoras', profile: null, profileKey: null, jobs: [], -}); + ...overrides, +}); -export const companyMailWithoutTokenMock = (): CompaniesEntity => ({ - ...companyMailMock(), - recoverPasswordToken: null, - mailConfirm: true, -}); +export const companyMailWithoutTokenMock = (): CompaniesEntity => + companyMailMock({ recoverPasswordToken: null, mailConfirm: true });Also applies to: 28-32
test/mocks/mail/job-mail.mock.ts (2)
5-31: Factory do job com overrides melhora reuso e legibilidade nos testesPermite construir variações de vaga sem duplicar objetos grandes.
-export const jobMailMock = (): JobsEntity => ({ +export const jobMailMock = (overrides: Partial<JobsEntity> = {}): JobsEntity => ({ id: '456e7890-e89b-12d3-a456-426614174001', title: 'Desenvolvedor Frontend Junior', description: 'Vaga para desenvolvedor frontend com foco em React', prerequisites: 'Conhecimento em React, JavaScript, HTML, CSS', benefits: 'Vale alimentação, Vale transporte, Plano de saúde', type: 'JUNIOR', typeContract: 'CLT', contractText: null, salaryMin: 3000, salaryMax: 5000, modality: 'REMOTE', federalUnit: 'SP', city: 'São Paulo', openEndedContract: true, contractType: null, affirmative: false, affirmativeType: null, status: StatusEnum.ACTIVE, content: null, company_id: '123e4567-e89b-12d3-a456-426614174000', createdAt: new Date('2023-01-01T00:00:00.000Z'), updatedAt: new Date('2023-01-01T00:00:00.000Z'), company: companyMailMock(), applications: [], comments: [], -}); + ...overrides, +});
33-49: List factory pode aproveitar o factory parametrizávelMantém o comportamento atual e deixa espaço para cenários customizados.
export const jobMailListMock = (): JobsEntity[] => [ - jobMailMock(), - { - ...jobMailMock(), - id: '456e7890-e89b-12d3-a456-426614174002', - title: 'Desenvolvedor Backend Junior', - description: 'Vaga para desenvolvedor backend com foco em Node.js', - prerequisites: 'Conhecimento em Node.js, TypeScript, Banco de dados', - }, - { - ...jobMailMock(), - id: '456e7890-e89b-12d3-a456-426614174003', - title: 'Desenvolvedor Fullstack Junior', - description: 'Vaga para desenvolvedor fullstack', - prerequisites: 'Conhecimento em React, Node.js, TypeScript', - }, + jobMailMock(), + jobMailMock({ + id: '456e7890-e89b-12d3-a456-426614174002', + title: 'Desenvolvedor Backend Junior', + description: 'Vaga para desenvolvedor backend com foco em Node.js', + prerequisites: 'Conhecimento em Node.js, TypeScript, Banco de dados', + }), + jobMailMock({ + id: '456e7890-e89b-12d3-a456-426614174003', + title: 'Desenvolvedor Fullstack Junior', + description: 'Vaga para desenvolvedor fullstack', + prerequisites: 'Conhecimento em React, Node.js, TypeScript', + }), ];test/modules/mail/services/mail.service.spec.ts (5)
24-26: Tipagem mais forte do mock do MailerServiceEvita casts ad-hoc e ajuda o IntelliSense/TS a pegar quebras cedo.
-const mailerServiceMock = { - sendMail: jest.fn(), -}; +const mailerServiceMock: jest.Mocked<MailerService> = { + sendMail: jest.fn(), +} as unknown as jest.Mocked<MailerService>; - let mailerService: { sendMail: jest.Mock }; + let mailerService: jest.Mocked<MailerService>; - mailerService = module.get(MailerService); + mailerService = module.get<MailerService>(MailerService) as jest.Mocked<MailerService>;Also applies to: 19-21, 39-41
42-47: Evite vazamento de estado de ambiente entre testesGuardar e restaurar
FRONTEND_URLisola os testes, útil caso outras suites dependam desse env.- process.env.FRONTEND_URL = 'https://frontend.test.com'; + const prevFrontendUrl = process.env.FRONTEND_URL; + process.env.FRONTEND_URL = 'https://frontend.test.com'; + // Restaura no final da suite + afterAll(() => { + if (prevFrontendUrl === undefined) { + delete process.env.FRONTEND_URL; + } else { + process.env.FRONTEND_URL = prevFrontendUrl; + } + });
72-89: URL comtoken=null: considere omitir o parâmetro quando não houver tokenO comportamento atual reflete o serviço, mas em UX/segurança é mais limpo não enviar
token=null. Se decidirem mudar o serviço, atualizem este teste removendo o parâmetrotokenquandonull.Posso abrir um PR de follow-up ajustando o serviço e os testes?
182-236: Cenários de alertas de vaga: cobertura equilibrada (lista, vazia, único)Boa validação da forma do payload para o template. Se futuramente o template exigir campos adicionais (ex.:
candidateName), sugiro acrescentar testes focados no shape docontext.
262-341: Tratamento de erros abrangenteÓtimo: repropaga mensagens do Mailer e cobre caso de timeout via
name. Se o serviço mapear erros para classes específicas (ex.:ServiceUnavailableException), valeria testar o tipo da exceção também.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (5)
test/mocks/mail/company-mail.mock.ts(1 hunks)test/mocks/mail/job-mail.mock.ts(1 hunks)test/mocks/mail/mail-options.mock.ts(1 hunks)test/mocks/mail/user-mail.mock.ts(1 hunks)test/modules/mail/services/mail.service.spec.ts(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (3)
test/modules/mail/services/mail.service.spec.ts (4)
test/mocks/mail/user-mail.mock.ts (2)
userMailMock(3-25)userMailWithoutTokenMock(27-31)test/mocks/mail/company-mail.mock.ts (2)
companyMailMock(3-26)companyMailWithoutTokenMock(28-32)test/mocks/mail/job-mail.mock.ts (2)
jobMailListMock(33-49)jobMailMock(5-31)test/mocks/mail/mail-options.mock.ts (1)
mailOptionsMock(3-12)
test/mocks/mail/job-mail.mock.ts (1)
test/mocks/mail/company-mail.mock.ts (1)
companyMailMock(3-26)
test/mocks/mail/mail-options.mock.ts (1)
test/mocks/mail/job-mail.mock.ts (1)
jobMailListMock(33-49)
🔇 Additional comments (1)
test/modules/mail/services/mail.service.spec.ts (1)
118-152: Cobertura de “no token” para empresa está boaValida ausência de
urlno contexto quando não há token, o que previne links inválidos ao usuário. Bom uso detoHaveBeenCalledWithpara pegar chaves extras indesejadas.
| expect(mailerService.sendMail).toHaveBeenCalledTimes(1); | ||
| expect(mailerService.sendMail).toHaveBeenCalledWith({ | ||
| to: company.email, | ||
| subject: 'Empresa criado!', |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Português: “Empresa criada!” (feminino) em vez de “Empresa criado!”
Assunto de e-mail é texto para o usuário. Corrigir concordância (“empresa” é feminino).
Sugestão no teste (ajuste aqui e alinhe o serviço se necessário):
- subject: 'Empresa criado!',
+ subject: 'Empresa criada!',Para checar a string usada no serviço, rode:
🏁 Script executed:
#!/bin/bash
# Busca o assunto no serviço real
rg -n -C2 "Empresa criado|Empresa criada" src/modules/mails/mail.service.tsLength of output: 241
Corrigir concordância de gênero em “Empresa criado!” para “Empresa criada!” no teste e no serviço
O texto do assunto do e-mail deve concordar com “empresa” (feminino). É preciso atualizar tanto o teste quanto o serviço real.
Locais a serem ajustados:
test/modules/mail/services/mail.service.spec.ts(linha 165)src/modules/mails/mail.service.ts(linha 90)
Exemplo de diff no teste:
--- a/test/modules/mail/services/mail.service.spec.ts
+++ b/test/modules/mail/services/mail.service.spec.ts
@@ -165,1 +165,1 @@
- subject: 'Empresa criado!',
+ subject: 'Empresa criada!',Exemplo de diff no serviço:
--- a/src/modules/mails/mail.service.ts
+++ b/src/modules/mails/mail.service.ts
@@ -88,4 +88,4 @@
to: email,
- subject: 'Empresa criado!',
+ subject: 'Empresa criada!',
template: './confirmEmailCompany',
context: {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| subject: 'Empresa criado!', | |
| subject: 'Empresa criada!', |
| subject: 'Empresa criado!', | |
| to: email, | |
| subject: 'Empresa criada!', | |
| template: './confirmEmailCompany', | |
| context: { |
🤖 Prompt for AI Agents
In test/modules/mail/services/mail.service.spec.ts around line 165 and
src/modules/mails/mail.service.ts around line 90, the email subject currently
reads "Empresa criado!" which is grammatically incorrect for the feminine noun
"empresa"; update both occurrences to "Empresa criada!". Modify the test
expectation at line 165 to match the corrected string and update the service
implementation at line 90 so the sent email subject uses "Empresa criada!" to
keep the test and runtime behavior consistent.
MikaelMelo1
left a comment
MikaelMelo1
left a comment
There was a problem hiding this comment.
Apenas alguns pontos para ajustes.
test/mocks/mail/company-mail.mock.ts
Outdated
| companySize: 'SMALL_SIZE', | ||
| uf: 'SP', | ||
| otherSite: { | ||
| instagran: 'https://instagram.com/testcompany', |
There was a problem hiding this comment.
Pode ajustar o "instagran" para "instagram".
test/mocks/mail/company-mail.mock.ts
Outdated
| password: 'hashedPassword123', | ||
| recoverPasswordToken: 'company-recover-token-456', | ||
| mailConfirm: false, | ||
| created_at: new Date('2023-01-01T00:00:00.000Z'), |
There was a problem hiding this comment.
Pode deixar apenas com a função
- new Date(), assim fica mais flexivel.
test/mocks/mail/company-mail.mock.ts
Outdated
| recoverPasswordToken: 'company-recover-token-456', | ||
| mailConfirm: false, | ||
| created_at: new Date('2023-01-01T00:00:00.000Z'), | ||
| updated_at: new Date('2023-01-01T00:00:00.000Z'), |
There was a problem hiding this comment.
Pode deixar apenas com a função
- new Date(), assim fica mais flexivel.
test/mocks/mail/job-mail.mock.ts
Outdated
| status: StatusEnum.ACTIVE, | ||
| content: null, | ||
| company_id: '123e4567-e89b-12d3-a456-426614174000', | ||
| createdAt: new Date('2023-01-01T00:00:00.000Z'), |
There was a problem hiding this comment.
Pode deixar apenas com a função
- new Date(), assim fica mais flexivel.
test/mocks/mail/job-mail.mock.ts
Outdated
| content: null, | ||
| company_id: '123e4567-e89b-12d3-a456-426614174000', | ||
| createdAt: new Date('2023-01-01T00:00:00.000Z'), | ||
| updatedAt: new Date('2023-01-01T00:00:00.000Z'), |
There was a problem hiding this comment.
Pode deixar apenas com a função
- new Date(), assim fica mais flexivel.
test/mocks/mail/user-mail.mock.ts
Outdated
| mailConfirm: false, | ||
| type: 'USER', | ||
| policies: true, | ||
| created_at: new Date('2023-01-01T00:00:00.000Z'), |
There was a problem hiding this comment.
Pode deixar apenas com a função
new Date(), assim fica mais flexivel.
test/mocks/mail/user-mail.mock.ts
Outdated
| type: 'USER', | ||
| policies: true, | ||
| created_at: new Date('2023-01-01T00:00:00.000Z'), | ||
| updated_at: new Date('2023-01-01T00:00:00.000Z'), |
There was a problem hiding this comment.
Pode deixar apenas com a função
new Date(), assim fica mais flexivel.
| expect(mailerService.sendMail).toHaveBeenCalledTimes(1); | ||
| expect(mailerService.sendMail).toHaveBeenCalledWith({ | ||
| to: company.email, | ||
| subject: 'Empresa criado!', |
There was a problem hiding this comment.
mude para "Empresa criada!"
test/mocks/mail/company-mail.mock.ts
Outdated
| companyName: 'Test Company LTDA', | ||
| email: 'company@example.com', | ||
| cnpj: '12345678000199', | ||
| password: 'hashedPassword123', |
There was a problem hiding this comment.
Tem uma função simples pra gerar dinamicamente, da uma pesquisada. Assim, não fica visivel a senha, mesmo sendo em mock.
- Corrigir imports relativos em mail.service.spec.ts e update-password-by-email.service.ts - Adicionar MailService mock em update-password-by-email.service.spec.ts - Atualizar mensagens esperadas de inglês para português nos testes
|
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
test/mocks/mail/job-mail.mock.ts (1)
33-49: Considere usar cópias independentes para evitar compartilhamento de referências.Ao usar o spread operator em
{...jobMailMock(), ...}, objetos aninhados comocompany,applications,commentse as instâncias deDatesão compartilhados por referência entre os itens do array. Se os testes modificarem esses objetos, pode ocorrer "poluição" entre testes.Para melhor isolamento, considere chamar
jobMailMock()individualmente para cada item:export const jobMailListMock = (): JobsEntity[] => [ jobMailMock(), { - ...jobMailMock(), + ...jobMailMock(), id: '456e7890-e89b-12d3-a456-426614174002', title: 'Desenvolvedor Backend Junior', description: 'Vaga para desenvolvedor backend com foco em Node.js', prerequisites: 'Conhecimento em Node.js, TypeScript, Banco de dados', }, { - ...jobMailMock(), + ...jobMailMock(), id: '456e7890-e89b-12d3-a456-426614174003', title: 'Desenvolvedor Fullstack Junior', description: 'Vaga para desenvolvedor fullstack', prerequisites: 'Conhecimento em React, Node.js, TypeScript', }, ];Ou, alternativamente, criar cada mock de forma independente:
export const jobMailListMock = (): JobsEntity[] => { const job1 = jobMailMock(); const job2 = jobMailMock(); job2.id = '456e7890-e89b-12d3-a456-426614174002'; job2.title = 'Desenvolvedor Backend Junior'; job2.description = 'Vaga para desenvolvedor backend com foco em Node.js'; job2.prerequisites = 'Conhecimento em Node.js, TypeScript, Banco de dados'; const job3 = jobMailMock(); job3.id = '456e7890-e89b-12d3-a456-426614174003'; job3.title = 'Desenvolvedor Fullstack Junior'; job3.description = 'Vaga para desenvolvedor fullstack'; job3.prerequisites = 'Conhecimento em React, Node.js, TypeScript'; return [job1, job2, job3]; };
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
.DS_Storeis excluded by!**/.DS_Storepackage-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (12)
docker-compose.yml(1 hunks)src/database/entities/companies.entity.ts(1 hunks)src/modules/mails/mail.module.ts(1 hunks)src/modules/mails/mail.service.ts(1 hunks)src/modules/user/dtos/create-user.dto.ts(1 hunks)src/modules/user/services/update-password-by-email.service.ts(1 hunks)test/mocks/mail/company-mail.mock.ts(1 hunks)test/mocks/mail/job-mail.mock.ts(1 hunks)test/mocks/mail/user-mail.mock.ts(1 hunks)test/modules/mail/services/mail.service.spec.ts(1 hunks)test/modules/user/services/recovery-password-by-email.service.spec.ts(2 hunks)test/modules/user/services/update-password-by-email.service.spec.ts(6 hunks)
✅ Files skipped from review due to trivial changes (1)
- src/modules/mails/mail.module.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- test/modules/mail/services/mail.service.spec.ts
- test/mocks/mail/company-mail.mock.ts
🧰 Additional context used
🧬 Code graph analysis (1)
test/mocks/mail/job-mail.mock.ts (1)
test/mocks/mail/company-mail.mock.ts (1)
companyMailMock(6-33)
🔇 Additional comments (9)
src/modules/mails/mail.service.ts (1)
90-90: Correção gramatical aprovada!A mudança de "Empresa criado!" para "Empresa criada!" corrige a concordância de gênero em português, já que "empresa" é substantivo feminino.
src/modules/user/dtos/create-user.dto.ts (1)
37-40: Refatoração de formatação aprovada.A mudança de formatação do decorador
@Matchespara uma única linha não altera o comportamento e mantém a mesma validação de regex.docker-compose.yml (2)
4-20: Atualização do serviço PostgreSQL aprovada.A renomeação do serviço de
database_soujuniorparapostgrese a atualização parapostgres:16-alpinesão melhorias válidas. As configurações de ambiente e healthcheck estão corretas.Verifique se as variáveis de ambiente no arquivo
.envestão alinhadas com as novas configurações (usuáriopostgres, senha123, bancovagas-api).
22-28: Adição do MailHog para testes de e-mail aprovada!A inclusão do serviço MailHog é uma excelente prática para testar o envio de e-mails em ambiente de desenvolvimento. As portas 1025 (SMTP) e 8025 (interface web) estão configuradas corretamente.
test/modules/user/services/recovery-password-by-email.service.spec.ts (1)
58-58: Localização das mensagens de teste aprovada.A atualização das mensagens esperadas para português mantém consistência com a localização da aplicação e facilita a manutenção dos testes pela equipe.
Also applies to: 80-80
test/modules/user/services/update-password-by-email.service.spec.ts (2)
2-2: Adição do mock do MailService aprovada!A inclusão do
MailServiceMockmelhora o isolamento dos testes, permitindo que oUpdatePasswordByEmailServiceseja testado independentemente da implementação real do serviço de e-mail.Also applies to: 12-14, 29-32, 38-38
56-56: Localização das mensagens de asserção aprovada.As mensagens de erro e sucesso foram corretamente atualizadas para português, mantendo consistência com a localização da aplicação.
Also applies to: 72-72, 89-89
test/mocks/mail/user-mail.mock.ts (1)
3-31: Implementação dos mocks aprovada!As funções de mock estão bem estruturadas:
userMailMock()fornece uma entidade completa com todos os campos necessáriosuserMailWithoutTokenMock()reutiliza o mock base e ajusta os campos específicos para o cenário sem token- O uso de
new Date()para timestamps garante flexibilidade nos testesA implementação segue boas práticas de teste e facilita a criação de cenários diferentes para os testes do serviço de e-mail.
test/mocks/mail/job-mail.mock.ts (1)
1-31: Mock bem estruturado e completo!A implementação do
jobMailMockestá correta e abrangente, incluindo todos os campos necessários da entidadeJobsEntity. O uso denew Date()nas linhas 26-27 mantém a flexibilidade dos timestamps, o que está alinhado com as sugestões de revisões anteriores.
| @Column({ type: 'json', nullable: true }) | ||
| otherSite: { | ||
| instagran: string; | ||
| instagram: string; |
There was a problem hiding this comment.
🧩 Analysis chain
Correção de typo importante, mas verifique o impacto.
A correção de "instagran" para "instagram" é necessária. No entanto, essa mudança pode quebrar código que referencia o nome antigo do campo. Verifique se há código que acessa otherSite.instagran e atualize-o para otherSite.instagram.
Execute o seguinte script para verificar referências ao campo antigo:
🏁 Script executed:
#!/bin/bash
# Descrição: Verificar referências ao campo "instagran" no código
# Buscar por referências ao nome antigo do campo
rg -n --type=ts 'instagran' -g '!*.entity.ts'Length of output: 179
Atualize o DTO para refletir a correção do campo "instagran" para "instagram".
A verificação identificou que o arquivo DTO ainda referencia o nome antigo do campo em dois locais:
src/modules/company/dtos/update-company.dto.ts:46— campo em dados de exemplosrc/modules/company/dtos/update-company.dto.ts:55— declaração da propriedade
Atualize ambas as referências de instagran para instagram para manter a consistência entre a entidade e o DTO, evitando erros em tempo de execução.
🤖 Prompt for AI Agents
src/database/entities/companies.entity.ts around line 66 and
src/modules/company/dtos/update-company.dto.ts lines ~46 and ~55: the entity
field was corrected from "instagran" to "instagram" but the DTO still uses the
old name; update the DTO by renaming both occurrences of "instagran" to
"instagram" (the example data at ~line 46 and the property declaration at ~line
55) so the DTO matches the entity and avoids runtime mismatches.
| import { Injectable } from '@nestjs/common'; | ||
| import * as bcrypt from 'bcrypt'; | ||
| import { MailService } from 'src/modules/mails/mail.service'; | ||
| import { MailService } from '../../mails/mail.service'; |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
🧩 Analysis chain
Verifique a consistência do estilo de imports.
A mudança de import absoluto para relativo é funcional, mas é importante manter consistência em toda a base de código. Verifique se o projeto adota um padrão específico para imports.
Execute o seguinte script para verificar o padrão de imports no projeto:
🏁 Script executed:
#!/bin/bash
# Descrição: Verificar padrão de imports para MailService
# Buscar imports absolutos do MailService
echo "=== Imports absolutos ==="
rg -n "from 'src/modules/mails/mail.service'" --type=ts
# Buscar imports relativos do MailService
echo "=== Imports relativos ==="
rg -n "from '\.\./.*mails/mail\.service'" --type=tsLength of output: 1775
Estabeleça um padrão consistente de imports em toda a base de código.
A verificação confirmou que o projeto não adota um padrão claro e uniforme para imports. Foram encontrados:
- 4 arquivos com imports absolutos (
from 'src/modules/mails/mail.service') - 10 arquivos com imports relativos (
from '../../mails/mail.service'ou variações)
Embora a mudança para imports relativos seja funcional e mantenha consistência dentro do módulo user/services, ela expõe uma inconsistência mais ampla no projeto. Recomenda-se:
- Definir um padrão de import único para toda a base de código (absoluto ou relativo)
- Aplicar esse padrão consistentemente em todos os serviços, especialmente nos módulos
user,company,jobsealert - Documentar a convenção escolhida no projeto
🤖 Prompt for AI Agents
src/modules/user/services/update-password-by-email.service.ts around line 3:
imports in this file (and across the repo) are inconsistent (mix of relative and
absolute imports); decide on one import style (pick either absolute using
tsconfig "paths" or relative) and apply it project-wide—update this file to use
the chosen style, adjust tsconfig/webpack settings if you choose absolute
imports, run a repo-wide replace or codemod to normalize imports in the user,
company, jobs and alert modules, add the chosen convention to the project README
or CONTRIBUTING, and run the linter/build to verify no import errors remain.
2 participants
Criando mocks e testes para rodar na entidade mail
Summary by CodeRabbit