Enhances CI workflow and tests#66
Conversation
Extends CI workflow to include the `develop` branch and upload test results. Uses Bogus to generate realistic fake data for unit tests, improving test coverage and reducing reliance on hardcoded values, thereby enhancing the reliability and maintainability of the tests.
WalkthroughEstende triggers da CI para incluir a branch develop e adiciona upload de artefato com resultados de teste; refatora vários testes unitários para usar Bogus/Faker gerando dados dinamicamente e adiciona a dependência Bogus ao projeto de testes ExternalServices. Changes
Estimated code review effort🎯 3 (Moderado) | ⏱️ ~20 minutos
Possibly related PRs
Suggested labels
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 |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
InvoiceReminder.ExternalServices.UnitTests/BarcodeReader/BarcodeReaderServiceTests.cs (1)
68-91: Testes unitários com mocks implementados corretamente.Os testes geram faturas esperadas via faker e configuram o mock do
_barcodeHandlerpara retornar essas faturas (linhas 75, 101). A abordagem de passarexpectedInvoice.Beneficiarycomo parâmetro (linhas 80, 106) garante consistência entre os dados de entrada e as asserções.💡 Sugestão opcional: unificar comprimento do código de barras
Foi observado que o comprimento do código de barras gerado difere entre os arquivos de teste:
BarcodeReaderServiceTests.csusa 44 caracteres (linha 46)SendMessageServiceTests.csusa 47 caracteres (linha 64 do outro arquivo)Embora isso não afete os testes atuais (pois o handler é mockado), considere padronizar o comprimento para 47 caracteres, que parece mais próximo do formato real de códigos de barras brasileiros.
-.RuleFor(i => i.Barcode, faker => faker.Random.AlphaNumeric(44)) +.RuleFor(i => i.Barcode, faker => faker.Random.AlphaNumeric(47))Also applies to: 94-117
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
.github/workflows/workflow-ci.yml(2 hunks)InvoiceReminder.API.UnitTests/Endpoints/LoginEndpointTests.cs(6 hunks)InvoiceReminder.API.UnitTests/Endpoints/ScanEmailDefinitionEndpointsTests.cs(17 hunks)InvoiceReminder.API.UnitTests/Endpoints/UserEndpointsTests.cs(18 hunks)InvoiceReminder.ExternalServices.UnitTests/BarcodeReader/BarcodeReaderServiceTests.cs(5 hunks)InvoiceReminder.ExternalServices.UnitTests/InvoiceReminder.ExternalServices.UnitTests.csproj(1 hunks)InvoiceReminder.ExternalServices.UnitTests/SendMessage/SendMessageServiceTests.cs(5 hunks)
🧰 Additional context used
🧬 Code graph analysis (4)
InvoiceReminder.ExternalServices.UnitTests/SendMessage/SendMessageServiceTests.cs (2)
InvoiceReminder.Domain/Entities/User.cs (2)
User(3-21)User(14-20)InvoiceReminder.Domain/Entities/EmailAuthToken.cs (1)
EmailAuthToken(3-12)
InvoiceReminder.API.UnitTests/Endpoints/LoginEndpointTests.cs (1)
InvoiceReminder.Authentication/Extensions/StringHashExtension.cs (1)
ToSHA256(9-15)
InvoiceReminder.ExternalServices.UnitTests/BarcodeReader/BarcodeReaderServiceTests.cs (4)
InvoiceReminder.ExternalServices/BarcodeReader/BarcodeReaderService.cs (1)
Invoice(21-56)InvoiceReminder.ExternalServices/BarcodeReader/AccountInvoiceBarcodeHandler.cs (1)
Invoice(8-22)InvoiceReminder.ExternalServices/BarcodeReader/BankInvoiceBarcodeHandler.cs (1)
Invoice(25-41)InvoiceReminder.Domain/Extensions/EntityExtensions.cs (1)
Guid(41-52)
InvoiceReminder.API.UnitTests/Endpoints/UserEndpointsTests.cs (2)
InvoiceReminder.Application.UnitTests/AppServices/UserAppServiceTests.cs (1)
Faker(29-43)InvoiceReminder.Domain/Abstractions/Result.cs (4)
Result(3-25)Result(9-14)Result(16-19)Result(21-24)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Analyze (csharp)
🔇 Additional comments (11)
InvoiceReminder.ExternalServices.UnitTests/InvoiceReminder.ExternalServices.UnitTests.csproj (1)
14-14: A adição do Bogus está alinhada com os objetivos do PR e está devidamente versionada.O Central Package Management está configurado e habilitado no projeto. A versão do Bogus (35.6.5) está corretamente especificada no
Directory.Packages.props, garantindo reproducibilidade das builds e consistência de versão entre ambientes. A omissão de versão explícita na referência do pacote está em conformidade com a estratégia de versionamento centralizado do projeto..github/workflows/workflow-ci.yml (1)
11-14: Extensão do CI para a branch develop está correta!A inclusão da branch
developnos triggers depull_requestepushestá alinhada com boas práticas de GitFlow e garante que o CI rode tanto na branch principal quanto na de desenvolvimento.InvoiceReminder.API.UnitTests/Endpoints/LoginEndpointTests.cs (2)
1-1: LGTM! Integração do Bogus implementada corretamente.A introdução da biblioteca Bogus para geração de dados de teste está bem estruturada. A configuração dos fakers é abrangente e realista, incluindo a geração adequada de senhas com hash SHA256.
Also applies to: 27-29, 42-56
58-105: Lógica de autenticação com senha está correta.O teste gera corretamente uma senha em texto plano (linha 63), utiliza essa senha para o
LoginRequest(linha 73), e configura oexpectedUsercom a senha em hash SHA256 (linha 67). Essa separação garante que o teste simula adequadamente o fluxo de autenticação real onde a senha é enviada em texto plano e comparada com o hash armazenado.InvoiceReminder.ExternalServices.UnitTests/SendMessage/SendMessageServiceTests.cs (2)
1-1: LGTM! Geração de dados de teste bem estruturada.A configuração dos fakers para múltiplas entidades (
Invoice,EmailAuthToken,ScanEmailDefinition,User) está bem implementada com valores realistas e relacionamentos apropriados. A inicialização de coleções vazias para o faker deUser(linhas 97-100) é uma boa prática que evita valores nulos inesperados.Also applies to: 25-28, 50-103
105-145: Teste com relacionamentos de entidades está correto.O teste gera corretamente entidades relacionadas: um
UsercomEmailAuthTokeneScanEmailDefinitionem suas coleções (linhas 111-115), e utiliza o beneficiário da definição de e-mail para criar o dicionário de anexos (linha 118). Essa abordagem simula adequadamente o cenário real de relacionamentos entre entidades.InvoiceReminder.API.UnitTests/Endpoints/UserEndpointsTests.cs (2)
1-1: LGTM! Configuração do Bogus implementada de forma consistente.A inicialização dos fakers para
UserViewModelestá bem estruturada com regras abrangentes para todos os campos relevantes. O uso deToUniversalTime()nas datas (linhas 48-49) é uma boa prática que garante consistência de fuso horário nos testes.Also applies to: 26-27, 40-50
127-154: Uso correto do padrão Clone() para customização.O uso de
_userViewModelFaker.Clone().RuleFor(u => u.Id, id).Generate()(linha 135) é uma excelente prática que permite customizar campos específicos (neste caso, o Id) mantendo os valores gerados pelo faker para os demais campos. Esse padrão é reutilizado consistentemente em outros testes.InvoiceReminder.ExternalServices.UnitTests/BarcodeReader/BarcodeReaderServiceTests.cs (1)
1-1: LGTM! Geração de dados de teste bem implementada.A configuração do faker para
Invoiceestá completa e realista, incluindo a lista de bancos brasileiros conhecidos (linhas 35-43) e valores apropriados para campos monetários e de datas.Also applies to: 20-21, 30-50
InvoiceReminder.API.UnitTests/Endpoints/ScanEmailDefinitionEndpointsTests.cs (2)
1-1: LGTM! Configuração do Bogus abrangente e realista.A inicialização do faker para
ScanEmailDefinitionViewModelestá excelente, incluindo:
- Uso de
PickRandompara o enumInvoiceType(linha 45)- Geração de nomes de empresas para beneficiários (linha 46)
- Geração de nomes de arquivos do sistema (linha 49)
- Datas em UTC para consistência (linhas 50-51)
Also applies to: 6-6, 26-27, 40-52
396-427: Geração de e-mail para testes implementada corretamente.O teste usa
_faker.Internet.Email()para gerar um e-mail (linha 400) e depois customiza oScanEmailDefinitionViewModelcom esse mesmo e-mail usandoClone().RuleFor()(linha 405). Essa abordagem garante que o e-mail usado na URL da requisição corresponde ao e-mail no objeto esperado, mantendo a consistência do teste.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
InvoiceReminder.ExternalServices.UnitTests/BarcodeReader/BarcodeReaderServiceTests.cs (2)
30-49: Considere simplificar a configuração do Faker para as necessidades atuais dos testes.A configuração do
_invoiceFakeré bastante detalhada, mas a maioria dos campos gerados (Id, UserId, Bank, Barcode, DueDate, CreatedAt, UpdatedAt) não são validados nas asserções dos testes atuais. As asserções verificam apenasBeneficiary, seBarcodenão é nulo/vazio, e seAmount > 0.Se a intenção é preparar para testes futuros mais abrangentes, a configuração atual está adequada. Caso contrário, você poderia simplificar gerando apenas os campos realmente necessários, melhorando a legibilidade e manutenibilidade.
💡 Sugestão de simplificação (se aplicável)
Se apenas alguns campos são necessários, considere uma abordagem mais enxuta:
- _invoiceFaker = new Faker<Invoice>() - .RuleFor(i => i.Id, faker => faker.Random.Guid()) - .RuleFor(i => i.UserId, faker => faker.Random.Guid()) - .RuleFor(i => i.Bank, faker => faker.PickRandom( - "Banco do Brasil", - "Bradesco", - "Itaú", - "Caixa Econômica Federal", - "Santander", - "Safra", - "Citibank", - "BTG Pactual")) - .RuleFor(i => i.Beneficiary, faker => faker.Company.CompanyName()) - .RuleFor(i => i.Amount, faker => faker.Finance.Amount(10, 10000)) - .RuleFor(i => i.Barcode, faker => faker.Random.AlphaNumeric(47)) - .RuleFor(i => i.DueDate, faker => faker.Date.Future().ToUniversalTime()) - .RuleFor(i => i.CreatedAt, faker => faker.Date.Past().ToUniversalTime()) - .RuleFor(i => i.UpdatedAt, faker => faker.Date.Recent().ToUniversalTime()); + _invoiceFaker = new Faker<Invoice>() + .RuleFor(i => i.Beneficiary, faker => faker.Company.CompanyName()) + .RuleFor(i => i.Amount, faker => faker.Finance.Amount(10, 10000)) + .RuleFor(i => i.Barcode, faker => faker.Random.AlphaNumeric(47));Alternativamente, mantenha a configuração completa se você planeja expandir as validações dos testes no futuro.
56-65: Simplificação opcional para teste de exceção.Neste teste, o valor do
beneficiaryé irrelevante, pois a exceção é lançada antes de ser utilizado (quando obyteStreamestá vazio). Usar o Faker aqui adiciona complexidade desnecessária.Para testes de exceção focados em validações de entrada, um valor simples e direto (como uma string literal) pode ser mais claro e manter o foco no que está sendo testado.
💡 Simplificação sugerida
- var beneficiary = _faker.Company.CompanyName(); + var beneficiary = "Any Beneficiary";Obs: Esta é apenas uma sugestão de estilo. A implementação atual está funcionalmente correta.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/workflow-ci.yml(2 hunks)InvoiceReminder.ExternalServices.UnitTests/BarcodeReader/BarcodeReaderServiceTests.cs(5 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/workflow-ci.yml
🧰 Additional context used
🧬 Code graph analysis (1)
InvoiceReminder.ExternalServices.UnitTests/BarcodeReader/BarcodeReaderServiceTests.cs (3)
InvoiceReminder.ExternalServices/BarcodeReader/BarcodeReaderService.cs (1)
Invoice(21-56)InvoiceReminder.ExternalServices/BarcodeReader/AccountInvoiceBarcodeHandler.cs (1)
Invoice(8-22)InvoiceReminder.ExternalServices/BarcodeReader/BankInvoiceBarcodeHandler.cs (1)
Invoice(25-41)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Analyze (csharp)
🔇 Additional comments (3)
InvoiceReminder.ExternalServices.UnitTests/BarcodeReader/BarcodeReaderServiceTests.cs (3)
1-1: Ótima adição da biblioteca Bogus!A integração do Bogus para geração de dados de teste dinâmicos é uma melhoria significativa em relação aos valores hard-coded, aumentando a manutenibilidade dos testes.
Also applies to: 20-21
68-91: Teste bem estruturado com uso adequado do Bogus.O teste utiliza corretamente os dados gerados pelo Faker e valida que o serviço lê o PDF, invoca o handler e retorna o resultado esperado. A estrutura Arrange/Act/Assert está clara e as asserções cobrem os pontos essenciais.
94-117: Teste consistente com a abordagem anterior.O teste para
BankInvoicesegue o mesmo padrão bem-estruturado do teste deAccountInvoice, garantindo cobertura consistente para ambos os tipos de fatura.
Extends CI workflow to include the
developbranch and upload test results.Uses Bogus to generate realistic fake data for unit tests, improving test coverage and reducing reliance on hardcoded values,
thereby enhancing the reliability and maintainability of the tests.
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.