Updates .NET packages to latest versions#65
Conversation
Updates .NET packages to their latest versions, including essential libraries and testing dependencies. This ensures the project benefits from the newest features, security patches, and performance improvements. Includes updates to bulk extensions library. Adds global.json to define the .NET SDK version, also adds bogus package to mock data for unit tests and improve testing data generation. Removes `MaxCpuCount` setting from `CodeCoverage.runsettings`.
jldsilva
added
.NET
WalkthroughRemoveu MaxCpuCount=1 de CodeCoverage.runsettings; adicionou global.json; reorganizou e atualizou versões em Directory.Packages.props (incl. grupo "Essentials" e EFCore.BulkExtensions); introduziu Bogus/Faker em muitos testes; refatorou mapeamento de endpoints em helpers privados com constantes basepath; ajustou BulkInsertAsync; adicionou step de locale no CI. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Áreas a revisar com atenção:
Possibly related PRs
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: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
InvoiceReminder.API/Endpoints/InvoiceEndpoints.cs (2)
40-55: Metadados de resposta inconsistentes com o comportamento real.O endpoint retorna
Results.NotFoundquando falha (linha 48), mas os metadados.Produces()não incluemStatus404NotFound. Compare comMapGetJobScheduleemJobScheduleEndpoints.csque inclui corretamente.Produces(StatusCodes.Status404NotFound).🔎 Sugestão de correção
.WithName("GetInvoice") .RequireAuthorization() .Produces(StatusCodes.Status200OK) + .Produces(StatusCodes.Status404NotFound) .Produces(StatusCodes.Status400BadRequest) .Produces(StatusCodes.Status500InternalServerError);
57-73: Mesmo problema: falta.Produces(StatusCodes.Status404NotFound).O endpoint
GetInvoiceByBarcodetambém retornaResults.NotFoundmas não declara esse status nos metadados.🔎 Sugestão de correção
.WithName("GetInvoiceByBarcode") .RequireAuthorization() .Produces(StatusCodes.Status200OK) + .Produces(StatusCodes.Status404NotFound) .Produces(StatusCodes.Status400BadRequest) .Produces(StatusCodes.Status500InternalServerError);
🧹 Nitpick comments (21)
InvoiceReminder.API/Exceptions/GlobalExceptionHandler.cs (1)
19-22: A verificação explícita deIsEnabledé redundante no .NET moderno.No .NET 6+ (e especialmente no .NET 8/10), os métodos de logging estruturado como
LogErrorjá realizam verificações internas deIsEnabled, tornando esta verificação explícita desnecessária. A otimização de desempenho pretendida já é aplicada automaticamente pelo framework.🔎 Simplificação sugerida
- if (_logger.IsEnabled(LogLevel.Error)) - { - _logger.LogError(exception, "An Exception occurred: {Message}", exception.Message); - } + _logger.LogError(exception, "An Exception occurred: {Message}", exception.Message);InvoiceReminder.API/Endpoints/SendMessageEndpoints.cs (1)
16-32: Método auxiliar bem estruturado. Considere revisar a lógica de tratamento de resultado.O método
MapSendMessageestá bem estruturado e segue as convenções do projeto. A refatoração está correta e preserva o comportamento existente.No entanto, vale revisar a lógica nas linhas 23-25: quando
resulté nulo ou vazio, o código retornaResults.Problem(result), passando uma string vazia ou nula para o método Problem, o que não fornece informações de erro significativas ao cliente. Considere retornar uma mensagem de erro mais descritiva nesses casos.💡 Sugestão de melhoria para tratamento de erros
-return !string.IsNullOrEmpty(result) - ? Results.Ok(result) - : Results.Problem(result); +return !string.IsNullOrEmpty(result) + ? Results.Ok(result) + : Results.Problem( + statusCode: StatusCodes.Status500InternalServerError, + title: "Erro ao enviar mensagem", + detail: "O serviço não retornou um resultado válido.");InvoiceReminder.Application.UnitTests/AppServices/JobScheduleAppServiceTests.cs (1)
51-66: Considere extrair as expressões cron duplicadas.O array de expressões cron nas linhas 56-63 é idêntico ao das linhas 39-46. Embora seja código de teste, você pode extrair essas expressões para uma constante privada para melhor manutenibilidade.
🔎 Refatoração sugerida para eliminar duplicação
+ private static readonly string[] ValidCronExpressions = + [ + "0 0/5 * * * ?", // Every 5 minutes + "0 0 * * * ?", // Every hour + "0 0 0 * * ?", // Every day at midnight + "0 0 0 ? * MON", // Every Monday + "0 0 0 1 * ?", // First day of month + "0 0 0 1 1 ?", // Every January 1st + "0 0 12 * * ?" // Every noon + ]; + private static Faker<JobSchedule> CreateJobScheduleFaker() { return new Faker<JobSchedule>() .RuleFor(j => j.Id, faker => faker.Random.Guid()) .RuleFor(j => j.UserId, faker => faker.Random.Guid()) - .RuleFor(j => j.CronExpression, faker => faker.PickRandom( - "0 0/5 * * * ?", // Every 5 minutes - "0 0 * * * ?", // Every hour - "0 0 0 * * ?", // Every day at midnight - "0 0 0 ? * MON", // Every Monday - "0 0 0 1 * ?", // First day of month - "0 0 0 1 1 ?", // Every January 1st - "0 0 12 * * ?")) // Every noon + .RuleFor(j => j.CronExpression, faker => faker.PickRandom(ValidCronExpressions)) .RuleFor(j => j.CreatedAt, faker => faker.Date.Past().ToUniversalTime()) .RuleFor(j => j.UpdatedAt, faker => faker.Date.Recent().ToUniversalTime()); } private static Faker<JobScheduleViewModel> CreateJobScheduleViewModelFaker() { return new Faker<JobScheduleViewModel>() .RuleFor(j => j.Id, faker => faker.Random.Guid()) .RuleFor(j => j.UserId, faker => faker.Random.Guid()) - .RuleFor(j => j.CronExpression, faker => faker.PickRandom( - "0 0/5 * * * ?", - "0 0 * * * ?", - "0 0 0 * * ?", - "0 0 0 ? * MON", - "0 0 0 1 * ?", - "0 0 0 1 1 ?", - "0 0 12 * * ?")) + .RuleFor(j => j.CronExpression, faker => faker.PickRandom(ValidCronExpressions)) .RuleFor(j => j.CreatedAt, faker => faker.Date.Past().ToUniversalTime()) .RuleFor(j => j.UpdatedAt, faker => faker.Date.Recent().ToUniversalTime()); }InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs (2)
210-211: Considere usar o faker existente para consistência.A criação de uma nova instância
Faker()para gerar nomes atualizados funciona, mas seria mais consistente usar o faker existente:_testEntityFaker.Generate().Nameou criar um método auxiliar.🔎 Refatoração sugerida para maior consistência
- var updatedName = new Faker().Lorem.Word(); + var updatedName = _testEntityFaker.Generate().Name;Also applies to: 242-243
266-268: Evite mutação do faker compartilhado.Chamar
RuleForno_testEntityFakercompartilhado modifica sua configuração permanentemente, o que pode causar testes instáveis se executados em paralelo ou em ordens diferentes. Cada chamada aRuleForsubstitui a regra anterior.🔎 Refatoração recomendada para isolamento de testes
Crie instâncias de faker locais com as regras específicas em vez de mutar o faker compartilhado:
// Arrange + var customFaker = new Faker<TestEntity>() + .RuleFor(e => e.Id, _ => Guid.NewGuid()); + var entities = new List<TestEntity> { - _testEntityFaker.RuleFor(e => e.Name, _ => "Test1").Generate(), - _testEntityFaker.RuleFor(e => e.Name, _ => "AnotherTest").Generate(), - _testEntityFaker.RuleFor(e => e.Name, _ => "Test2").Generate() + customFaker.RuleFor(e => e.Name, _ => "Test1").Generate(), + customFaker.Clone().RuleFor(e => e.Name, _ => "AnotherTest").Generate(), + customFaker.Clone().RuleFor(e => e.Name, _ => "Test2").Generate() };Ou de forma ainda mais simples:
var entities = new List<TestEntity> { - _testEntityFaker.RuleFor(e => e.Name, _ => "Test1").Generate(), - _testEntityFaker.RuleFor(e => e.Name, _ => "AnotherTest").Generate(), - _testEntityFaker.RuleFor(e => e.Name, _ => "Test2").Generate() + new TestEntity { Id = Guid.NewGuid(), Name = "Test1" }, + new TestEntity { Id = Guid.NewGuid(), Name = "AnotherTest" }, + new TestEntity { Id = Guid.NewGuid(), Name = "Test2" } };InvoiceReminder.Infrastructure.UnitTests/Data/Repository/UserRepositoryTests.cs (3)
34-48: Considere alinhar com o padrão de método usado em outros testes.A implementação funciona corretamente com
[TestInitialize]. Porém, outros arquivos de teste no projeto (comoUserAppServiceTests.cseUserExtensionsTests.cs) utilizam um padrão de método que retorna um novoFaker<User>(ex:CreateUserFaker()), em vez de armazenar em um campo.Para consistência com o restante da codebase, considere refatorar para o padrão de método:
🔎 Sugestão de refatoração
- private Faker<User> _userFaker; - - [TestInitialize] - public void Setup() - { - InitializeFaker(); - } - - private void InitializeFaker() - { - _userFaker = new Faker<User>() + private static Faker<User> CreateUserFaker() => + new Faker<User>() .RuleFor(u => u.Id, _ => Guid.NewGuid()) .RuleFor(u => u.TelegramChatId, f => f.Random.Long(100000000, long.MaxValue)) .RuleFor(u => u.Name, f => f.Person.FullName) .RuleFor(u => u.Email, f => f.Internet.Email()) .RuleFor(u => u.Password, f => f.Internet.Password(length: 16, memorable: false)); - }
72-75: Criação redundante deFakere mutação do faker compartilhado.Linha 72 cria um novo
Faker()apenas para gerar o email, quando_userFakerjá possui essa capacidade. Além disso, encadear.RuleFor()diretamente em_userFakermodifica a instância compartilhada. Embora funcione devido ao[TestInitialize], usar.Clone()torna a intenção mais clara:🔎 Sugestão de refatoração
- var email = new Faker().Internet.Email(); - var user = _userFaker + var user = _userFaker.Clone() .RuleFor(u => u.Email, _ => email) .Generate(); + var email = user.Email;Ou, de forma mais idiomática:
- var email = new Faker().Internet.Email(); - var user = _userFaker - .RuleFor(u => u.Email, _ => email) - .Generate(); + var user = _userFaker.Generate(); + var email = user.Email;
98-100: Mesmo padrão de mutação do faker compartilhado.Similar ao teste anterior, considere usar
.Clone()antes de encadear.RuleFor()para evitar mutação da instância compartilhada:🔎 Sugestão de refatoração
- var user = _userFaker + var user = _userFaker.Clone() .RuleFor(u => u.Id, _ => userId) .Generate();InvoiceReminder.API/Endpoints/ScanEmailDefinitionEndpoints.cs (1)
24-155: Métodos Map implementados de forma consistente e correta!*Todos os sete métodos seguem um padrão uniforme e mantêm o comportamento original dos endpoints:
- Assinaturas consistentes recebendo
RouteGroupBuilder- Autorização adequadamente configurada em todos os endpoints
- Tratamento de erros uniforme com verificação de
IsSuccess- Nomenclatura clara e descritiva
- Configurações OpenAPI apropriadas
A modularização facilita a manutenção futura e torna o código mais testável. A formatação dos parâmetros no método
MapDeleteScanEmailDefinition(linha 141) também está adequada para melhor legibilidade.💡 Sugestão opcional: Consistência na documentação OpenAPI
Alguns endpoints GET que retornam
Results.NotFound()(comoMapGetScanEmailDefinitioneMapGetByUserId) não incluemStatus404NotFoundnos atributos.Produces(). Para maior consistência na documentação OpenAPI, considere adicionar:.Produces(StatusCodes.Status200OK) +.Produces(StatusCodes.Status404NotFound) .Produces(StatusCodes.Status400BadRequest) .Produces(StatusCodes.Status500InternalServerError);Nota: Esta é uma observação sobre código pré-existente, não introduzida por esta refatoração.
InvoiceReminder.Application.UnitTests/AppServices/UserAppServiceTests.cs (2)
29-39: Considere inicializar coleções de navegação para consistência.O método
CreateUserFaker()configura propriedades básicas doUser, mas não inicializa propriedades de coleção. O arquivoUserExtensionsTests.csmostra um padrão onde coleções comoInvoices,JobSchedules,EmailAuthTokenseScanEmailDefinitionssão inicializadas como arrays vazios.Embora os testes atuais possam funcionar sem essas inicializações (se o mapeamento
UserViewModelnão incluir essas propriedades), inicializá-las evita possíveis exceções de referência nula e mantém consistência com outros testes no projeto.🔎 Sugestão para alinhar com o padrão de UserExtensionsTests.cs
private static Faker<User> CreateUserFaker() { return new Faker<User>() .RuleFor(u => u.Id, faker => faker.Random.Guid()) .RuleFor(u => u.Name, faker => faker.Person.FullName) .RuleFor(u => u.Email, faker => faker.Internet.Email()) .RuleFor(u => u.Password, faker => faker.Random.AlphaNumeric(32)) .RuleFor(u => u.TelegramChatId, faker => faker.Random.Long(1000000, 9999999999)) .RuleFor(u => u.CreatedAt, faker => faker.Date.Past().ToUniversalTime()) - .RuleFor(u => u.UpdatedAt, faker => faker.Date.Recent().ToUniversalTime()); + .RuleFor(u => u.UpdatedAt, faker => faker.Date.Recent().ToUniversalTime()) + .RuleFor(u => u.Invoices, _ => []) + .RuleFor(u => u.JobSchedules, _ => []) + .RuleFor(u => u.EmailAuthTokens, _ => []) + .RuleFor(u => u.ScanEmailDefinitions, _ => []); }
61-64: Considere simplificar a geração de dados do teste.O código gera um email separadamente e depois sobrescreve o email do usuário com esse valor. Uma abordagem mais simples seria gerar o usuário primeiro e usar o email gerado automaticamente pelo
CreateUserFaker().🔎 Sugestão de simplificação
-var email = _faker.Internet.Email(); -var user = CreateUserFaker() - .RuleFor(u => u.Email, email) - .Generate(); +var user = CreateUserFaker().Generate(); +var email = user.Email;Isso elimina a redundância e torna o código mais direto, já que o faker já gera um email válido.
InvoiceReminder.Application.UnitTests/AppServices/BaseAppServiceTests.cs (1)
279-279: Modificadores de classe apropriados para entidades de teste.A mudança para
public sealed classé uma boa prática, prevenindo herança não intencional e garantindo que as classes de teste permaneçam simples e focadas. A visibilidade pública permite que o Bogus e o Mapster trabalhem corretamente com essas entidades.💡 Sugestão opcional: Considere adicionar mais propriedades para testes mais realistas
Embora a implementação atual esteja correta para os testes existentes, considere adicionar propriedades como
Id,CreatedAteUpdatedAtàs classes de teste para torná-las mais alinhadas com entidades reais e permitir testes mais abrangentes no futuro. Isso seguiria o padrão observado emJobScheduleAppServiceTests.cs.public sealed class TestEntity { + public Guid Id { get; set; } public string Name { get; set; } + public DateTime CreatedAt { get; set; } + public DateTime UpdatedAt { get; set; } } public sealed class TestEntityViewModel { + public Guid Id { get; set; } public string Name { get; set; } + public DateTime CreatedAt { get; set; } + public DateTime UpdatedAt { get; set; } }E atualize os fakers:
_entityFaker = new Faker<TestEntity>() + .RuleFor(e => e.Id, faker => faker.Random.Guid()) - .RuleFor(e => e.Name, faker => faker.Person.FullName); + .RuleFor(e => e.Name, faker => faker.Person.FullName) + .RuleFor(e => e.CreatedAt, faker => faker.Date.Past().ToUniversalTime()) + .RuleFor(e => e.UpdatedAt, faker => faker.Date.Recent().ToUniversalTime()); _entityViewModelFaker = new Faker<TestEntityViewModel>() + .RuleFor(e => e.Id, faker => faker.Random.Guid()) - .RuleFor(e => e.Name, faker => faker.Person.FullName); + .RuleFor(e => e.Name, faker => faker.Person.FullName) + .RuleFor(e => e.CreatedAt, faker => faker.Date.Past().ToUniversalTime()) + .RuleFor(e => e.UpdatedAt, faker => faker.Date.Recent().ToUniversalTime());Nota: Esta é apenas uma sugestão opcional para melhorar o realismo dos testes. A implementação atual está funcional e adequada.
Also applies to: 284-284
InvoiceReminder.Infrastructure.UnitTests/Data/Repository/ScanEmailDefinitionRepositoryTests.cs (2)
76-80: Considere evitar mutação do campo Faker compartilhado.O teste funciona corretamente e a asserção adicional em
Beneficiary(linha 94) melhora a cobertura. Porém, chamar.RuleFor()diretamente no campo_scanEmailDefinitionFakermutá-lo. Embora o[TestInitialize]redefina o Faker antes de cada teste, um padrão mais claro seria criar uma instância local ou usar um método auxiliar:var scanEmailDefinition = new Faker<ScanEmailDefinition>() .RuleFor(s => s.Id, _ => Guid.NewGuid()) .RuleFor(s => s.UserId, _ => userId) .RuleFor(s => s.Beneficiary, _ => beneficiary) // ... outras regras conforme necessário .Generate();Isso torna explícito que você está criando uma configuração específica para este teste.
Also applies to: 94-94
103-107: Refatoração consistente com asserções aprimoradas.Os testes foram consistentemente refatorados para usar Bogus, e as asserções adicionais (linha 121 para
SenderEmailAddresse linha 147 para contagem) melhoram a validação. A mesma sugestão sobre evitar mutação do campo_scanEmailDefinitionFakerse aplica aqui.Alternativamente, você poderia criar um método auxiliar:
private Faker<ScanEmailDefinition> CreateFaker(Action<Faker<ScanEmailDefinition>> configure = null) { var faker = new Faker<ScanEmailDefinition>() .RuleFor(s => s.Id, _ => Guid.NewGuid()) .RuleFor(s => s.InvoiceType, f => f.PickRandom<InvoiceType>()) // ... outras regras padrão ; configure?.Invoke(faker); return faker; } // Uso: var scanEmailDefinition = CreateFaker(f => f .RuleFor(s => s.UserId, _ => userId) .RuleFor(s => s.SenderEmailAddress, _ => senderEmail)) .Generate();Also applies to: 121-121, 130-132, 147-147
InvoiceReminder.DomainEntities.UnitTests/Extensions/UserExtensionsTests.cs (1)
40-43: Parâmetrofakernão utilizado nas regras de coleção.As regras para as coleções (
Invoices,JobSchedules,EmailAuthTokens,ScanEmailDefinitions) incluem o parâmetrofakermas não o utilizam. Considere usar_em vez defakerpara indicar claramente que o parâmetro não é usado.🔎 Refatoração sugerida
- .RuleFor(u => u.Invoices, faker => invoices ?? new HashSet<Invoice>()) - .RuleFor(u => u.JobSchedules, faker => jobSchedules ?? new HashSet<JobSchedule>()) - .RuleFor(u => u.EmailAuthTokens, faker => emailAuthTokens ?? new HashSet<EmailAuthToken>()) - .RuleFor(u => u.ScanEmailDefinitions, faker => scanEmailDefinitions ?? new HashSet<ScanEmailDefinition>()); + .RuleFor(u => u.Invoices, _ => invoices ?? new HashSet<Invoice>()) + .RuleFor(u => u.JobSchedules, _ => jobSchedules ?? new HashSet<JobSchedule>()) + .RuleFor(u => u.EmailAuthTokens, _ => emailAuthTokens ?? new HashSet<EmailAuthToken>()) + .RuleFor(u => u.ScanEmailDefinitions, _ => scanEmailDefinitions ?? new HashSet<ScanEmailDefinition>());InvoiceReminder.API/Endpoints/InvoiceEndpoints.cs (1)
9-9: Considere usar PascalCase para constantes.A convenção de nomenclatura em C# recomenda
PascalCasepara constantes. Sugiro renomearbasepathparaBasePath.🔎 Sugestão de correção
- private const string basepath = "/api/invoice"; + private const string BasePath = "/api/invoice";InvoiceReminder.API/Endpoints/LoginEndpoints.cs (2)
11-11: Considere usar PascalCase para constantes.Assim como em
InvoiceEndpoints.cs, a convenção C# recomendaPascalCasepara constantes.
20-20: Tipo de parâmetro inconsistente com outros arquivos de endpoints.O método
MapLoginrecebeIEndpointRouteBuilder, mas todos os outros arquivos de endpoints (comoInvoiceEndpoints.cs,JobScheduleEndpoints.cs) usamRouteGroupBuilderpara os métodosMapXxx. Isso funciona, mas é inconsistente.🔎 Sugestão de correção para consistência
- private static void MapLogin(IEndpointRouteBuilder endpoints) + private static void MapLogin(RouteGroupBuilder endpoint) { - _ = endpoints.MapPost("/", + _ = endpoint.MapPost("/",InvoiceReminder.API/Endpoints/JobScheduleEndpoints.cs (1)
9-9: Considere usar PascalCase para constantes.Assim como nos outros arquivos de endpoints, a convenção C# recomenda
PascalCasepara constantes (BasePath).InvoiceReminder.API/Endpoints/UserEndpoints.cs (2)
77-95: Considere usar ID em vez de email na URL do recurso criado.A linha 87 usa o email na URL do recurso criado (
$"{basepath}/{result.Value.Email}"), mas isso apresenta alguns desafios:
- Emails podem conter caracteres especiais que requerem encoding de URL
- O endpoint
GetUser(linha 44) usa/{id}, criando inconsistência- A convenção REST tipicamente usa IDs de recursos em URLs
🔎 Sugestão de correção
return result.IsSuccess - ? Results.Created($"{basepath}/{result.Value.Email}", result.Value) + ? Results.Created($"{basepath}/{result.Value.Id}", result.Value) : Results.Problem(result.Error);
97-118: Considere ajustar a URL do recurso criado para operações em lote.A linha 110 retorna
$"{basepath}/"como URL do recurso criado, que inclui uma barra final mas não aponta para um recurso específico. Para operações em lote, considere:
- Remover a barra final:
Results.Created(basepath, result.Value)- Ou usar uma URL mais específica:
Results.Created($"{basepath}/bulk-insert", result.Value)
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (33)
CodeCoverage.runsettings(0 hunks)Directory.Packages.props(1 hunks)InvoiceReminder.API.UnitTests/Endpoints/InvoiceEndpointsTests.cs(14 hunks)InvoiceReminder.API.UnitTests/Endpoints/JobScheduleEndPointsTests.cs(11 hunks)InvoiceReminder.API.UnitTests/InvoiceReminder.API.UnitTests.csproj(1 hunks)InvoiceReminder.API/Endpoints/GoogleOAuthEndpoints.cs(3 hunks)InvoiceReminder.API/Endpoints/InvoiceEndpoints.cs(6 hunks)InvoiceReminder.API/Endpoints/JobScheduleEndpoints.cs(6 hunks)InvoiceReminder.API/Endpoints/LoginEndpoints.cs(1 hunks)InvoiceReminder.API/Endpoints/ScanEmailDefinitionEndpoints.cs(7 hunks)InvoiceReminder.API/Endpoints/SendMessageEndpoints.cs(1 hunks)InvoiceReminder.API/Endpoints/UserEndpoints.cs(6 hunks)InvoiceReminder.API/Exceptions/GlobalExceptionHandler.cs(1 hunks)InvoiceReminder.Application.UnitTests/AppServices/BaseAppServiceTests.cs(9 hunks)InvoiceReminder.Application.UnitTests/AppServices/EmailAuthTokenAppServiceTests.cs(4 hunks)InvoiceReminder.Application.UnitTests/AppServices/InvoiceAppServiceTests.cs(4 hunks)InvoiceReminder.Application.UnitTests/AppServices/JobScheduleAppServiceTests.cs(6 hunks)InvoiceReminder.Application.UnitTests/AppServices/ScanEmailDefinitionAppServiceTests.cs(8 hunks)InvoiceReminder.Application.UnitTests/AppServices/UserAppServiceTests.cs(4 hunks)InvoiceReminder.Application.UnitTests/InvoiceReminder.Application.UnitTests.csproj(1 hunks)InvoiceReminder.Data/InvoiceReminder.Data.csproj(1 hunks)InvoiceReminder.Data/Repository/BaseRepository.cs(2 hunks)InvoiceReminder.DomainEntities.UnitTests/Extensions/EntityExtensionsTests.cs(12 hunks)InvoiceReminder.DomainEntities.UnitTests/Extensions/UserExtensionsTests.cs(28 hunks)InvoiceReminder.DomainEntities.UnitTests/InvoiceReminder.DomainEntities.UnitTests.csproj(1 hunks)InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs(15 hunks)InvoiceReminder.Infrastructure.UnitTests/Data/Repository/ScanEmailDefinitionRepositoryTests.cs(7 hunks)InvoiceReminder.Infrastructure.UnitTests/Data/Repository/UserRepositoryTests.cs(6 hunks)InvoiceReminder.Infrastructure.UnitTests/InvoiceReminder.Infrastructure.UnitTests.csproj(1 hunks)InvoiceReminder.JobScheduler.UnitTests/HostedService/QuartzHostedServiceTests.cs(9 hunks)InvoiceReminder.JobScheduler.UnitTests/InvoiceReminder.JobScheduler.UnitTests.csproj(1 hunks)InvoiceReminder.sln(1 hunks)global.json(1 hunks)
💤 Files with no reviewable changes (1)
- CodeCoverage.runsettings
🧰 Additional context used
🧬 Code graph analysis (12)
InvoiceReminder.API/Endpoints/GoogleOAuthEndpoints.cs (6)
InvoiceReminder.API/Endpoints/InvoiceEndpoints.cs (1)
RegisterEndpoints(11-21)InvoiceReminder.API/Endpoints/JobScheduleEndpoints.cs (1)
RegisterEndpoints(11-21)InvoiceReminder.API/Endpoints/LoginEndpoints.cs (1)
RegisterEndpoints(13-18)InvoiceReminder.API/Endpoints/ScanEmailDefinitionEndpoints.cs (1)
RegisterEndpoints(11-22)InvoiceReminder.API/Endpoints/SendMessageEndpoints.cs (1)
RegisterEndpoints(9-14)InvoiceReminder.API/Endpoints/UserEndpoints.cs (1)
RegisterEndpoints(12-23)
InvoiceReminder.Application.UnitTests/AppServices/EmailAuthTokenAppServiceTests.cs (3)
InvoiceReminder.Application.UnitTests/AppServices/UserAppServiceTests.cs (1)
Faker(29-39)InvoiceReminder.Domain/Entities/EmailAuthToken.cs (1)
EmailAuthToken(3-12)InvoiceReminder.Domain/Extensions/EntityExtensions.cs (1)
Guid(41-52)
InvoiceReminder.Application.UnitTests/AppServices/JobScheduleAppServiceTests.cs (3)
InvoiceReminder.Application.UnitTests/AppServices/ScanEmailDefinitionAppServiceTests.cs (1)
Faker(30-42)InvoiceReminder.Application.UnitTests/AppServices/UserAppServiceTests.cs (1)
Faker(29-39)InvoiceReminder.Domain/Entities/JobSchedule.cs (1)
JobSchedule(3-7)
InvoiceReminder.DomainEntities.UnitTests/Extensions/EntityExtensionsTests.cs (1)
InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs (1)
TestEntity(341-347)
InvoiceReminder.API/Endpoints/LoginEndpoints.cs (6)
InvoiceReminder.API/Endpoints/GoogleOAuthEndpoints.cs (1)
RegisterEndpoints(9-16)InvoiceReminder.API/Endpoints/InvoiceEndpoints.cs (1)
RegisterEndpoints(11-21)InvoiceReminder.API/Endpoints/JobScheduleEndpoints.cs (1)
RegisterEndpoints(11-21)InvoiceReminder.API/Endpoints/ScanEmailDefinitionEndpoints.cs (1)
RegisterEndpoints(11-22)InvoiceReminder.API/Endpoints/SendMessageEndpoints.cs (1)
RegisterEndpoints(9-14)InvoiceReminder.API/Endpoints/UserEndpoints.cs (1)
RegisterEndpoints(12-23)
InvoiceReminder.Application.UnitTests/AppServices/BaseAppServiceTests.cs (2)
InvoiceReminder.Application.UnitTests/AppServices/JobScheduleAppServiceTests.cs (2)
Faker(34-49)Faker(51-66)InvoiceReminder.Data/Repository/BaseRepository.cs (3)
Task(22-27)Task(29-40)Task(52-55)
InvoiceReminder.Infrastructure.UnitTests/Data/Repository/UserRepositoryTests.cs (4)
InvoiceReminder.Application.UnitTests/AppServices/InvoiceAppServiceTests.cs (1)
Faker(28-48)InvoiceReminder.Application.UnitTests/AppServices/JobScheduleAppServiceTests.cs (2)
Faker(34-49)Faker(51-66)InvoiceReminder.Application.UnitTests/AppServices/UserAppServiceTests.cs (1)
Faker(29-39)InvoiceReminder.DomainEntities.UnitTests/Extensions/UserExtensionsTests.cs (1)
Faker(31-44)
InvoiceReminder.Infrastructure.UnitTests/Data/Repository/ScanEmailDefinitionRepositoryTests.cs (1)
InvoiceReminder.Data/Repository/ScanEmailDefinitionRepository.cs (3)
Task(24-65)Task(67-108)Task(110-150)
InvoiceReminder.Application.UnitTests/AppServices/UserAppServiceTests.cs (3)
InvoiceReminder.Application.UnitTests/AppServices/InvoiceAppServiceTests.cs (1)
Faker(28-48)InvoiceReminder.DomainEntities.UnitTests/Extensions/UserExtensionsTests.cs (1)
Faker(31-44)InvoiceReminder.Domain/Extensions/EntityExtensions.cs (1)
Guid(41-52)
InvoiceReminder.API/Endpoints/UserEndpoints.cs (6)
InvoiceReminder.API/Endpoints/GoogleOAuthEndpoints.cs (1)
RegisterEndpoints(9-16)InvoiceReminder.API/Endpoints/InvoiceEndpoints.cs (1)
RegisterEndpoints(11-21)InvoiceReminder.API/Endpoints/JobScheduleEndpoints.cs (1)
RegisterEndpoints(11-21)InvoiceReminder.API/Endpoints/LoginEndpoints.cs (1)
RegisterEndpoints(13-18)InvoiceReminder.API/Endpoints/ScanEmailDefinitionEndpoints.cs (1)
RegisterEndpoints(11-22)InvoiceReminder.API/Endpoints/SendMessageEndpoints.cs (1)
RegisterEndpoints(9-14)
InvoiceReminder.API/Endpoints/JobScheduleEndpoints.cs (6)
InvoiceReminder.API/Endpoints/GoogleOAuthEndpoints.cs (1)
RegisterEndpoints(9-16)InvoiceReminder.API/Endpoints/InvoiceEndpoints.cs (1)
RegisterEndpoints(11-21)InvoiceReminder.API/Endpoints/LoginEndpoints.cs (1)
RegisterEndpoints(13-18)InvoiceReminder.API/Endpoints/ScanEmailDefinitionEndpoints.cs (1)
RegisterEndpoints(11-22)InvoiceReminder.API/Endpoints/SendMessageEndpoints.cs (1)
RegisterEndpoints(9-14)InvoiceReminder.API/Endpoints/UserEndpoints.cs (1)
RegisterEndpoints(12-23)
InvoiceReminder.API/Endpoints/SendMessageEndpoints.cs (6)
InvoiceReminder.API/Endpoints/GoogleOAuthEndpoints.cs (1)
RegisterEndpoints(9-16)InvoiceReminder.API/Endpoints/InvoiceEndpoints.cs (1)
RegisterEndpoints(11-21)InvoiceReminder.API/Endpoints/JobScheduleEndpoints.cs (1)
RegisterEndpoints(11-21)InvoiceReminder.API/Endpoints/LoginEndpoints.cs (1)
RegisterEndpoints(13-18)InvoiceReminder.API/Endpoints/ScanEmailDefinitionEndpoints.cs (1)
RegisterEndpoints(11-22)InvoiceReminder.API/Endpoints/UserEndpoints.cs (1)
RegisterEndpoints(12-23)
⏰ 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 (76)
InvoiceReminder.API/Endpoints/GoogleOAuthEndpoints.cs (4)
7-16: Refatoração limpa e consistente com padrões do projeto.A extração dos mapeamentos de endpoints para métodos auxiliares privados melhora a organização e manutenibilidade do código. O padrão é consistente com outros arquivos de endpoints no projeto (InvoiceEndpoints, UserEndpoints, LoginEndpoints, etc.).
18-33: Implementação correta do endpoint GetAuthUrl.O método implementa corretamente o mapeamento do endpoint com:
- Requisito de autorização apropriado (usuário precisa estar autenticado)
- Tratamento de erros adequado usando o padrão Result
- Documentação completa dos códigos de status HTTP
35-51: Endpoint de callback OAuth configurado corretamente.A implementação está correta para um endpoint de callback OAuth:
AllowAnonymous()é apropriado, pois o Google redireciona para este endpoint- Parâmetros
stateecodeseguem o padrão OAuth 2.0- Implementação assíncrona com
CancellationTokenestá adequada
53-68: Endpoint de revogação implementado adequadamente.O endpoint de revogação está bem implementado com:
- Verbo HTTP DELETE apropriado para a operação de revogação
- Requisito de autorização correto (usuário precisa estar autenticado)
- Tratamento assíncrono adequado com suporte a cancelamento
InvoiceReminder.Infrastructure.UnitTests/InvoiceReminder.Infrastructure.UnitTests.csproj (1)
20-20: Adição apropriada da biblioteca Bogus para geração de dados de teste.O pacote Bogus não possui dependências, reduzindo a superfície de ataque. A versão mais recente é 35.6.5, que é estável e ativamente mantida. A ausência de número de versão é consistente com o padrão de Gerenciamento Central de Pacotes utilizado no projeto.
InvoiceReminder.Application.UnitTests/AppServices/ScanEmailDefinitionAppServiceTests.cs (4)
1-1: Ótima adição da biblioteca Bogus para geração de dados de teste!A introdução do Bogus é uma prática recomendada que melhora a manutenibilidade dos testes ao substituir valores hard-coded por dados gerados dinamicamente.
Also applies to: 7-7
19-19: Implementação correta do campo Faker!O campo
_fakerestá adequadamente declarado comoreadonlye inicializado no construtor, seguindo boas práticas de teste.Also applies to: 27-28
30-42: Excelente implementação do método helper para geração de dados!O método
CreateScanEmailDefinitionFaker()está bem estruturado:
- Configura todas as propriedades da entidade com geradores apropriados
- Utiliza
ToUniversalTime()para datas, garantindo consistência de fuso horário- Permite sobrescrever regras específicas quando necessário (padrão builder)
- Usa
PickRandom<InvoiceType>()para valores do enum de domínio
64-69: Refatoração consistente e bem executada nos testes!Todas as modificações nos métodos de teste seguem um padrão consistente:
- Valores primitivos (GUIDs, emails, nomes) são gerados através do
_faker- Entidades complexas utilizam
CreateScanEmailDefinitionFaker()com sobrescrita de propriedades específicas quando necessário- A geração de múltiplas entidades (linha 185) usa
.Generate(3)adequadamente- Os testes mantêm sua cobertura e assertivas originais
A mudança melhora significativamente a manutenibilidade sem alterar o comportamento dos testes.
Also applies to: 96-97, 123-128, 155-156, 182-186, 211-211
InvoiceReminder.API/Endpoints/SendMessageEndpoints.cs (2)
7-8: Excelente! Constante de rota base centralizada.A definição da constante
basepathestá consistente com o padrão utilizado em todos os outros arquivos de endpoints (LoginEndpoints, GoogleOAuthEndpoints, InvoiceEndpoints, etc.). Isso centraliza a configuração da rota e facilita manutenções futuras.
9-14: Refatoração consistente com o padrão estabelecido.A refatoração do método
RegisterEndpointspara usarMapGroupe um método auxiliar está alinhada com o padrão utilizado em todos os outros endpoints do projeto. Isso melhora a consistência e manutenibilidade do código.InvoiceReminder.Application.UnitTests/AppServices/JobScheduleAppServiceTests.cs (4)
1-1: Importação apropriada do Bogus.A adição da biblioteca Bogus para geração de dados de teste está alinhada com os objetivos da PR e é consistente com outros arquivos de teste no projeto.
21-32: Inicialização do Faker corretamente implementada.O campo
_fakerestá adequadamente declarado comoreadonlye inicializado no construtor, seguindo boas práticas para fixtures de teste.
34-49: Método helper bem estruturado e consistente.O método
CreateJobScheduleFaker()configura corretamente todas as propriedades da entidadeJobSchedulee segue o mesmo padrão utilizado em outros testes do projeto (comoUserAppServiceTestseScanEmailDefinitionAppServiceTests). As expressões cron estão no formato válido para Quartz.
110-110: Uso apropriado dos fakers nos testes.A integração do Bogus nos testes está implementada corretamente:
- Geração de view models com
CreateJobScheduleViewModelFaker().Generate()- Geração de valores simples com
_faker.Random.Guid()- Uso de
RuleForpara sobrescrever propriedades específicas ao gerar múltiplas instânciasEssas mudanças melhoram a variabilidade dos dados de teste e reduzem a dependência de valores hardcoded.
Also applies to: 136-140, 165-165
InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs (3)
1-16: Ótima adição do Bogus para geração de dados de teste.A introdução da biblioteca Bogus e o campo
_testEntityFakermelhoram significativamente a manutenibilidade dos testes ao centralizar a geração de dados.
33-33: Inicialização bem estruturada do Faker.A configuração do faker no método
Setupgarante que cada teste tenha uma instância limpa e configurada adequadamente.Also applies to: 44-49
60-60: Uso consistente do Faker em todos os testes.A substituição da criação manual de entidades por
_testEntityFaker.Generate()torna os testes mais limpos e consistentes.Also applies to: 77-77, 101-101, 119-119, 141-141, 179-179, 203-203, 232-232
InvoiceReminder.Infrastructure.UnitTests/Data/Repository/UserRepositoryTests.cs (2)
1-1: LGTM! Integração do Bogus para geração de dados de teste.A adição da biblioteca Bogus e do campo
_userFakersegue o padrão já estabelecido em outros testes do projeto.Also applies to: 19-19
89-89: Boa adição de asserção!Verificar que
result.Idnão éGuid.Emptymelhora a cobertura do teste e valida que a geração de dados está funcionando corretamente.InvoiceReminder.API/Endpoints/ScanEmailDefinitionEndpoints.cs (2)
9-10: Excelente adição da constante basepath!A centralização do caminho base em uma constante melhora a manutenibilidade e facilita futuras alterações. A constante é utilizada de forma consistente tanto no
MapGroupquanto na construção do URI de respostaCreated.
11-22: Refatoração bem executada do método RegisterEndpoints!A extração dos registros de endpoints para métodos privados dedicados melhora significativamente a legibilidade e organização do código. O método
RegisterEndpointsagora fornece uma visão clara de todos os endpoints disponíveis sem sobrecarregar com detalhes de implementação.InvoiceReminder.Application.UnitTests/AppServices/EmailAuthTokenAppServiceTests.cs (5)
1-1: Excelente adoção do Bogus para geração de dados de teste!A introdução da biblioteca Bogus está alinhada com o padrão adotado em outros testes do projeto (como visto em
UserAppServiceTests.cs), melhorando a manutenibilidade e proporcionando dados de teste mais realistas e variados.
16-16: Inicialização adequada da instância Faker.A instância
_fakeré corretamente declarada comoreadonlye inicializada no construtor, permitindo seu reúso em todos os métodos de teste. O padrão está consistente com outras classes de teste no projeto.Also applies to: 24-25
27-39: Implementação robusta do helper de geração de dados.O método
CreateEmailAuthTokenFakerestá muito bem estruturado:
- Cobre todas as propriedades da entidade
EmailAuthToken- Utiliza valores realistas (ex: provedores "Google", "Microsoft", "GitHub")
- Aplica
.ToUniversalTime()em todas as datas para garantir consistência UTC- Define
AccessTokenExpirycomDate.Future(), garantindo que tokens gerados não estejam expirados por padrão- Segue o mesmo padrão observado em
UserAppServiceTests.cs
61-61: Refatoração correta do teste com dados gerados.A substituição de valores codificados manualmente pela geração via Faker está implementada corretamente:
userIdgerado dinamicamente com_faker.Random.Guid()emailAuthTokencriado através do helper com sobrescritas apropriadas deUserIdeTokenProvider- A lógica do teste permanece intacta, apenas o método de geração de dados foi aprimorado
Also applies to: 63-66
91-91: Consistência na geração de dados de teste.O uso de
_faker.Random.Guid()para geraruserIdestá consistente com as modificações no primeiro teste, mantendo o padrão uniforme em toda a classe.InvoiceReminder.Application.UnitTests/AppServices/BaseAppServiceTests.cs (7)
1-1: Excelente integração do Bogus para geração de dados de teste!A introdução da biblioteca Bogus melhora significativamente a manutenibilidade dos testes ao substituir dados codificados por dados gerados dinamicamente. A configuração dos fakers está correta e apropriada para as entidades de teste simples utilizadas.
Also applies to: 17-18, 28-32
39-39: Ótima substituição de dados codificados por dados gerados!O uso de
_entityViewModelFaker.Generate()melhora a qualidade dos testes ao fornecer dados variados em cada execução, tornando os testes mais robustos.
95-95: Geração de coleção implementada corretamente.O uso de
Generate(2)gera adequadamente uma coleção de 2 view models, mantendo a lógica do teste intacta enquanto melhora a variabilidade dos dados.
140-140: Dados gerados apropriadamente para o teste GetAll.A geração de múltiplas entidades com
_entityFaker.Generate(2)mantém a cobertura do teste enquanto adiciona variabilidade aos dados.
162-162: Melhorias na geração de dados e identificadores únicos.O uso de
_entityFaker.Generate()combinado comGuid.NewGuid()garante dados de teste únicos e variados em cada execução, melhorando o isolamento entre testes.Also applies to: 167-167
184-185: GUID dinâmico melhora a qualidade do teste.A substituição do GUID codificado por
Guid.NewGuid()garante identificadores únicos em cada execução do teste, tornando-o mais realista e robusto.
207-207: Uso consistente de dados gerados nos testes de remoção e atualização.A geração de view models com
_entityViewModelFaker.Generate()está correta e alinhada com as assinaturas dos métodos testados, mantendo a consistência em toda a suite de testes.Also applies to: 244-244
InvoiceReminder.Infrastructure.UnitTests/Data/Repository/ScanEmailDefinitionRepositoryTests.cs (3)
1-1: Importações corretas para suporte ao Bogus.As importações estão adequadas:
Boguspara geração de dados de teste eInvoiceReminder.Domain.Enumspara o tipoInvoiceTypeusado na configuração do Faker.Also applies to: 6-6
20-20: Inicialização adequada do Faker com TestInitialize.A declaração do campo e o método
Setupcom[TestInitialize]garantem que o Faker seja recriado antes de cada teste, evitando contaminação entre testes. Padrão correto para MSTest.Also applies to: 35-39
41-51: Configuração completa e apropriada do Faker.O método
InitializeFakerconfigura corretamente todas as propriedades deScanEmailDefinitioncom geradores apropriados do Bogus. A escolha dos métodos (Company.CompanyName, Internet.Email, System.FileName, etc.) está adequada para cada tipo de propriedade.InvoiceReminder.DomainEntities.UnitTests/Extensions/UserExtensionsTests.cs (1)
1-609: Excelente refatoração para uso da biblioteca Bogus!A migração de dados de teste codificados manualmente para geração baseada em Faker melhora significativamente a manutenibilidade dos testes. A abordagem é consistente e o método auxiliar
UserFakeroferece flexibilidade para diferentes cenários de teste. Os testes mantêm sua lógica e asserções originais enquanto se beneficiam de dados gerados dinamicamente.InvoiceReminder.DomainEntities.UnitTests/Extensions/EntityExtensionsTests.cs (6)
1-1: Ótima adição da biblioteca Bogus!A importação da biblioteca Bogus é apropriada e permite a geração de dados de teste mais realistas e manuteníveis em comparação com valores codificados.
16-18: Configuração adequada do gerador de dados!A inicialização do
_entityFakercom regras paraIdeNameestá bem estruturada e será reutilizada consistentemente nos testes.Note que não há uma seed definida, o que significa que os dados gerados serão diferentes a cada execução. Isso é aceitável para estes testes, pois eles comparam as mesmas instâncias geradas dentro de cada método. Se houver necessidade de reproduzibilidade entre execuções, considere adicionar
.UseSeed(valor)no futuro.
38-38: Excelente refatoração para usar dados gerados!A substituição de valores codificados por dados gerados via
_entityFaker.Generate()melhora significativamente a manutenibilidade dos testes. O padrão está aplicado consistentemente e as asserções foram corretamente atualizadas para referenciar as propriedades das entidades geradas.Also applies to: 79-80, 122-122, 124-124, 141-141, 200-201
57-60: Uso intencional e correto de instâncias locais do Faker.A criação de instâncias locais de
Fakernestes testes específicos é apropriada e necessária. Estes testes precisam de controle preciso sobre propriedades específicas:
- Testes de duplicação (linhas 57-60, 99-104, 219-223): Requerem múltiplas entidades com o mesmo
Idpara verificar a lógica de detecção de duplicatas- Testes de GUID vazio (linhas 161-162, 180-182): Necessitam de
Guid.Emptypara validar casos extremosA abordagem mista (_entityFaker
para casos gerais eFaker` local para controle específico) demonstra um bom entendimento dos requisitos de cada teste.Also applies to: 99-104, 161-162, 180-182, 219-223
197-213: Teste do HashSet está correto!O teste verifica adequadamente que o método
AddIfNotExistsfunciona com coleções do tipoHashSet. O método utiliza comparação baseada em ID internamente (via reflexão no métodoGetId), não dependendo da semântica de igualdade da coleção, portanto a ausência de override deEquals/GetHashCodeemTestEntitynão afeta a validade do teste.
1-1: O pacote Bogus é seguro e não apresenta vulnerabilidades conhecidas.A análise de segurança do pacote Bogus não detectou riscos relacionados a malware, manipulação de código ou vulnerabilidades conhecidas. A versão atual 35.6.5 (lançada em 25 de outubro de 2025) está atualizada e o pacote não possui dependências externas, reduzindo a superfície de ataque.
InvoiceReminder.Data/Repository/BaseRepository.cs (2)
1-1: Adição do namespace alinhada com a migração de pacote.A adição do
using EFCore.BulkExtensionsestá correta e alinhada com a migração de Z.EntityFramework.Extensions.EFCore para EFCore.BulkExtensions.Dotnet10.
37-37: Verifique se o parâmetrocancellationTokené aceito pelo métodoBulkInsertAsync.A sintaxe de parâmetro nomeado
cancellationToken: cancellationTokené válida em C#, porém não foi possível confirmar em documentação pública se a versão do EFCore.BulkExtensions utilizada aceita explicitamente este parâmetro. Outras versões dessa biblioteca usam parâmetros comobulkConfigcom sintaxe similar. Confirme a assinatura do método na documentação ou código-fonte da biblioteca em uso.InvoiceReminder.DomainEntities.UnitTests/InvoiceReminder.DomainEntities.UnitTests.csproj (1)
19-19: Adição adequada do Bogus para geração de dados de teste.A adição do pacote Bogus é uma melhoria apropriada para facilitar a geração de dados fictícios nos testes unitários, reduzindo a necessidade de dados codificados manualmente.
InvoiceReminder.JobScheduler.UnitTests/InvoiceReminder.JobScheduler.UnitTests.csproj (1)
18-18: Adição do Bogus consistente com melhorias nos testes.A inclusão do Bogus neste projeto de testes está alinhada com as melhorias de geração de dados de teste aplicadas em outros projetos da solução.
InvoiceReminder.API.UnitTests/InvoiceReminder.API.UnitTests.csproj (1)
19-19: Adição do Bogus para testes de API.A inclusão do pacote Bogus nos testes de API facilitará a criação de ViewModels e DTOs de teste com dados realistas.
InvoiceReminder.Application.UnitTests/InvoiceReminder.Application.UnitTests.csproj (1)
19-19: Adição do Bogus para testes da camada de aplicação.A inclusão do Bogus nos testes da camada de aplicação permitirá gerar dados de teste mais robustos e variados para os serviços.
InvoiceReminder.sln (1)
68-68: Adição correta do global.json aos itens da solução.A inclusão do arquivo global.json nos itens da solução está correta e torna o arquivo de configuração visível e facilmente acessível no Solution Explorer.
global.json (1)
1-9: Atualize para o .NET SDK 10.0.101 (versão mais recente).A versão "10.0.100" é válida — .NET 10 foi lançado em 9 de dezembro de 2025. No entanto, a versão mais recente disponível atualmente é 10.0.101. Considere atualizar para garantir patches e melhorias mais recentes.
Likely an incorrect or invalid review comment.
InvoiceReminder.Data/InvoiceReminder.Data.csproj (1)
9-10: Confirme a intenção de usar versões pré-lançamento do adaptador de bulk extensions.A migração do pacote antigo foi completada com sucesso — nenhuma referência a Z.EntityFramework.Extensions.EFCore permanece no código. No entanto, a pesquisa revela que os pacotes em uso (EFCore.BulkExtensions.Dotnet10) estão em status pré-lançamento (RC):
- A versão estável atual é 9.0.2 (tanto para o pacote principal quanto para o adaptador PostgreSQL)
- A versão v10 do adaptador PostgreSQL ainda não foi lançada oficialmente como estável
- O projeto está usando versões de pré-lançamento que podem ser instáveis em produção
Se a escolha de versões pré-lançamento é intencional, documente o motivo. Caso contrário, considere migrar para a versão estável 9.0.2 ou aguardar o lançamento oficial do v10 para PostgreSQL.
InvoiceReminder.API/Endpoints/InvoiceEndpoints.cs (4)
11-21: Boa refatoração para modularidade.A extração dos mapeamentos de endpoints para métodos privados
MapXxxmelhora a legibilidade e manutenibilidade do código. O padrão está consistente com os outros arquivos de endpoints no projeto.
23-38: LGTM!O método
MapGetInvoicesestá corretamente implementado com tratamento de resultado, autorização e metadados OpenAPI.
75-91: LGTM!O método
MapCreateInvoiceestá corretamente implementado e utiliza a constantebasepathpara construir a URL de localização noResults.Created.
93-127: LGTM!Os métodos
MapUpdateInvoiceeMapDeleteInvoiceestão corretamente implementados com os metadados de resposta apropriados.InvoiceReminder.API/Endpoints/LoginEndpoints.cs (1)
22-48: LGTM!A lógica de autenticação está correta. O endpoint valida credenciais, usa
AllowAnonymous()apropriadamente, e retorna os códigos de status corretos (200, 400, 401, 500).InvoiceReminder.API.UnitTests/Endpoints/InvoiceEndpointsTests.cs (4)
26-27: Boa adição do Bogus para geração de dados de teste.A introdução do Faker melhora a qualidade dos testes ao usar dados variados em vez de valores fixos.
42-59: LGTM!A configuração do
Faker<InvoiceViewModel>está bem estruturada com regras apropriadas para cada propriedade.
70-71: LGTM!O uso de
.Generate(2)para criar uma lista de invoices é apropriado e não modifica a instância compartilhada.
407-408: LGTM!O uso de
.Generate()sem modificar regras é seguro.InvoiceReminder.Application.UnitTests/AppServices/InvoiceAppServiceTests.cs (3)
28-48: Excelente padrão de factory method para o Faker.O método
CreateInvoiceFaker()retorna uma nova instância deFaker<Invoice>a cada chamada, evitando problemas de mutação de estado compartilhado. Este é o padrão correto que deveria ser aplicado também emInvoiceEndpointsTests.cs.
70-73: LGTM!O uso de
CreateInvoiceFaker().RuleFor(...).Generate()é seguro pois cada chamada cria uma nova instância do Faker.
1-26: LGTM!A integração do Bogus está bem implementada com o campo
_fakerpara geração de dados simples e o factory method para objetos complexos.Directory.Packages.props (4)
54-54: LGTM!A adição do Bogus 35.6.5 está alinhada com as mudanças nos testes unitários.
46-50: LGTM!As atualizações de Scalar.AspNetCore, SonarAnalyzer.CSharp e Telegram.Bot são incrementais e apropriadas.
33-34: Nomes de pacote NuGet incorretos.Os pacotes
EFCore.BulkExtensions.Dotnet10eEFCore.BulkExtensions.Dotnet10.PostgreSqlnão existem no NuGet. Os sufixos corretos são:.SqlServer/PostgreSql/MySql/Oracle/Sqlite. Além disso, apenas SqlServer e SQLite estão publicados como 10.0.0 RC, enquanto outros provedores ainda não foram atualizados para .NET 10. Corrija os nomes dos pacotes ou aguarde a disponibilidade da versão .NET 10 para PostgreSQL.Likely an incorrect or invalid review comment.
7-28: Excelente organização dos pacotes essenciais do .NET.A criação de um grupo separado para pacotes essenciais com versão consistente (10.0.1) melhora a manutenibilidade. .NET 10.0.1 foi lançado em dezembro de 2025 com correções não relacionadas a segurança incluindo atualizações no Runtime, ASP.NET Core, SDK, WinForms e Entity Framework Core.
InvoiceReminder.API/Endpoints/JobScheduleEndpoints.cs (4)
11-21: LGTM!A refatoração para usar métodos
MapXxxestá bem implementada e consistente com os outros arquivos de endpoints.
40-56: Bom exemplo de metadados OpenAPI corretos.Este endpoint corretamente inclui
.Produces(StatusCodes.Status404NotFound)para documentar o status de retorno quando o recurso não é encontrado.InvoiceEndpoints.csdeveria seguir este padrão.
77-94: LGTM!O método
MapCreateJobScheduleestá corretamente implementado comCancellationTokenno lambda e uso adequado da constantebasepathpara a URL de criação.
96-132: LGTM!Os métodos
MapUpdateJobScheduleeMapDeleteJobScheduleestão bem implementados com tratamento de resultado apropriado.InvoiceReminder.API/Endpoints/UserEndpoints.cs (1)
10-23: Excelente refatoração para métodos privados!A extração das configurações de endpoints para métodos privados melhora a legibilidade e segue o padrão estabelecido em outros arquivos de endpoints do projeto (LoginEndpoints.cs, GoogleOAuthEndpoints.cs, InvoiceEndpoints.cs).
InvoiceReminder.API.UnitTests/Endpoints/JobScheduleEndPointsTests.cs (1)
26-52: Excelente implementação do Bogus para geração de dados de teste!A configuração do
Faker<JobScheduleViewModel>está bem estruturada:
- Inclui todas as propriedades necessárias (Id, UserId, CronExpression, CreatedAt, UpdatedAt)
- As expressões cron são realistas e cobrem vários cenários comuns
- Datas são geradas apropriadamente (passado para CreatedAt, recente para UpdatedAt)
Essa abordagem melhora significativamente a manutenibilidade dos testes ao eliminar dados codificados e permitir geração de dados variados.
InvoiceReminder.JobScheduler.UnitTests/HostedService/QuartzHostedServiceTests.cs (1)
21-50: Excelente isolamento de testes com TestInitialize!A implementação do
[TestInitialize]e doInitializeFakerdemonstra práticas exemplares de teste:
- Limpa
_schedulesantes de cada teste, prevenindo poluição entre testes- Reinicializa o faker para garantir configuração consistente
- Usa uma expressão cron válida por padrão ("0/5 * * * * ?")
- Inicializa
_schedulescomo lista vazia no construtor (linha 31)Essa abordagem melhora significativamente o isolamento e a confiabilidade dos testes.
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Nitpick comments (4)
InvoiceReminder.DomainEntities.UnitTests/Extensions/UserExtensionsTests.cs (2)
25-25: Considere usar apenas caracteres numéricos para códigos de barras.Códigos de barras tipicamente contêm apenas dígitos. O uso de
faker.Random.AlphaNumeric(44)pode gerar dados que não correspondem às restrições do domínio.🔎 Sugestão de ajuste
- .RuleFor(e => e.Barcode, faker => faker.Random.AlphaNumeric(44)) + .RuleFor(e => e.Barcode, faker => faker.Random.Replace("############################################"))
31-31: Considere adicionar variedade nas expressões cron.A expressão cron está fixa em "0 9 * * *". Para maior variedade nos testes, considere gerar diferentes expressões válidas.
🔎 Sugestão de ajuste
- .RuleFor(e => e.CronExpression, faker => "0 9 * * *"); + .RuleFor(e => e.CronExpression, faker => $"0 {faker.Random.Int(0, 23)} * * *");InvoiceReminder.Application.UnitTests/AppServices/UserAppServiceTests.cs (1)
35-36: Considere alinhar a geração de dados com outros arquivos de teste para consistência.Para melhor manutenibilidade, considere:
- Senha (linha 35): Usar
faker.Internet.Password()em vez defaker.Random.AlphaNumeric(32)para consistência comUserExtensionsTests.cseUserRepositoryTests.cs- TelegramChatId (linha 36): O intervalo difere de outros testes (
UserRepositoryTests.csusaLong(100000000, long.MaxValue))Embora funcionais para testes, essas diferenças podem dificultar a manutenção futura.
🔎 Sugestão de alinhamento com outros testes
- .RuleFor(u => u.Password, faker => faker.Random.AlphaNumeric(32)) - .RuleFor(u => u.TelegramChatId, faker => faker.Random.Long(1000000, 9999999999)) + .RuleFor(u => u.Password, faker => faker.Internet.Password()) + .RuleFor(u => u.TelegramChatId, faker => faker.Random.Long(1))InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs (1)
210-211: Considere otimizar a geração do nome atualizado.O código gera uma entidade completa apenas para extrair a propriedade
Name. Embora funcional, uma abordagem mais direta seria usar_testEntityFaker.Generate().Namediretamente ounew Faker().Lorem.Word()para evitar a criação desnecessária de outros campos.🔎 Sugestão de refatoração
- var updatedName = _testEntityFaker.Generate().Name; - entity.Name = updatedName; + entity.Name = _testEntityFaker.Generate().Name;Also applies to: 242-243
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (13)
.github/workflows/workflow-ci.yml(1 hunks)InvoiceReminder.API.UnitTests/Endpoints/InvoiceEndpointsTests.cs(14 hunks)InvoiceReminder.API/Endpoints/InvoiceEndpoints.cs(6 hunks)InvoiceReminder.API/Endpoints/ScanEmailDefinitionEndpoints.cs(7 hunks)InvoiceReminder.API/Endpoints/SendMessageEndpoints.cs(1 hunks)InvoiceReminder.API/Endpoints/UserEndpoints.cs(6 hunks)InvoiceReminder.Application.UnitTests/AppServices/BaseAppServiceTests.cs(9 hunks)InvoiceReminder.Application.UnitTests/AppServices/JobScheduleAppServiceTests.cs(6 hunks)InvoiceReminder.Application.UnitTests/AppServices/UserAppServiceTests.cs(4 hunks)InvoiceReminder.DomainEntities.UnitTests/Extensions/UserExtensionsTests.cs(29 hunks)InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs(15 hunks)InvoiceReminder.Infrastructure.UnitTests/Data/Repository/ScanEmailDefinitionRepositoryTests.cs(6 hunks)InvoiceReminder.Infrastructure.UnitTests/Data/Repository/UserRepositoryTests.cs(5 hunks)
🚧 Files skipped from review as they are similar to previous changes (5)
- InvoiceReminder.Infrastructure.UnitTests/Data/Repository/ScanEmailDefinitionRepositoryTests.cs
- InvoiceReminder.API.UnitTests/Endpoints/InvoiceEndpointsTests.cs
- InvoiceReminder.Infrastructure.UnitTests/Data/Repository/UserRepositoryTests.cs
- InvoiceReminder.API/Endpoints/SendMessageEndpoints.cs
- InvoiceReminder.API/Endpoints/InvoiceEndpoints.cs
🧰 Additional context used
🧬 Code graph analysis (6)
InvoiceReminder.Application.UnitTests/AppServices/JobScheduleAppServiceTests.cs (1)
InvoiceReminder.Domain/Entities/JobSchedule.cs (1)
JobSchedule(3-7)
InvoiceReminder.Application.UnitTests/AppServices/UserAppServiceTests.cs (3)
InvoiceReminder.DomainEntities.UnitTests/Extensions/UserExtensionsTests.cs (1)
Faker(52-68)InvoiceReminder.Infrastructure.UnitTests/Data/Repository/UserRepositoryTests.cs (1)
Faker(33-41)InvoiceReminder.Domain/Extensions/EntityExtensions.cs (1)
Guid(41-52)
InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs (3)
InvoiceReminder.Application.UnitTests/AppServices/BaseAppServiceTests.cs (1)
TestEntity(285-291)InvoiceReminder.Domain/Extensions/EntityExtensions.cs (1)
Guid(41-52)InvoiceReminder.Data/Repository/BaseRepository.cs (5)
BaseRepository(8-94)BaseRepository(15-20)Task(22-27)Task(29-40)Task(52-55)
InvoiceReminder.API/Endpoints/UserEndpoints.cs (3)
InvoiceReminder.API/Endpoints/LoginEndpoints.cs (1)
RegisterEndpoints(13-18)InvoiceReminder.API/Endpoints/GoogleOAuthEndpoints.cs (1)
RegisterEndpoints(9-16)InvoiceReminder.Domain/Extensions/EntityExtensions.cs (1)
Guid(41-52)
InvoiceReminder.DomainEntities.UnitTests/Extensions/UserExtensionsTests.cs (5)
InvoiceReminder.Domain/Entities/JobSchedule.cs (1)
JobSchedule(3-7)InvoiceReminder.Domain/Entities/EmailAuthToken.cs (1)
EmailAuthToken(3-12)InvoiceReminder.Domain/Entities/ScanEmailDefinition.cs (1)
ScanEmailDefinition(5-13)InvoiceReminder.Domain/Extensions/EntityExtensions.cs (1)
Guid(41-52)InvoiceReminder.Domain/Entities/User.cs (2)
User(3-21)User(14-20)
InvoiceReminder.API/Endpoints/ScanEmailDefinitionEndpoints.cs (3)
InvoiceReminder.API/Endpoints/SendMessageEndpoints.cs (1)
RegisterEndpoints(9-14)InvoiceReminder.API/Endpoints/LoginEndpoints.cs (1)
RegisterEndpoints(13-18)InvoiceReminder.API/Endpoints/GoogleOAuthEndpoints.cs (1)
RegisterEndpoints(9-16)
⏰ 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 (26)
InvoiceReminder.API/Endpoints/ScanEmailDefinitionEndpoints.cs (3)
9-10: Excelente refatoração com a introdução da constante basepath!A centralização do caminho base em uma constante melhora a manutenibilidade e segue o princípio DRY. Esta abordagem está consistente com o padrão adotado em outros endpoints do projeto (LoginEndpoints, SendMessageEndpoints, GoogleOAuthEndpoints).
15-22: Ótima modularização dos endpoints!A extração dos registros de endpoints em métodos privados dedicados (MapGetScanEmailDefinitions, MapGetScanEmailDefinition, etc.) melhora significativamente a legibilidade e organização do código, tornando cada endpoint mais fácil de manter e testar individualmente.
56-56: Melhoria na documentação da API com adição de códigos 404!A inclusão de
.Produces(StatusCodes.Status404NotFound)nos endpoints GET (GetScanEmailDefinition, GetByUserId, GetBySenderEmailAddress) melhora a precisão da documentação OpenAPI/Swagger, refletindo corretamente o comportamento quando recursos não são encontrados.Also applies to: 75-75, 97-97
InvoiceReminder.API/Endpoints/UserEndpoints.cs (3)
10-11: Consistência na refatoração com introdução do basepath!A centralização do caminho base segue o mesmo padrão de refatoração aplicado em ScanEmailDefinitionEndpoints e outros endpoints do projeto, garantindo consistência arquitetural em toda a aplicação.
16-23: Modularização dos endpoints bem executada!A extração dos sete endpoints (MapGetUsers, MapGetUser, MapGetUserByEmail, MapCreateUser, MapCreateUsers, MapUpdateUser, MapDeleteUser) em métodos privados melhora a organização do código e facilita manutenção futura. O padrão está consistente com as demais refatorações no projeto.
87-87: Uso correto do basepath nas respostas Created!As respostas Created utilizam apropriadamente a constante basepath para gerar as URIs de localização dos recursos:
- Linha 87:
/api/user/{id}para criação individual- Linha 110:
/api/userpara inserção em loteIsso garante consistência e facilita futuras mudanças no caminho base.
Also applies to: 110-110
InvoiceReminder.DomainEntities.UnitTests/Extensions/UserExtensionsTests.cs (5)
1-3: LGTM!As importações estão corretas para suportar a geração de dados de teste com Bogus e os enums necessários.
12-50: Excelente progresso na configuração dos fakers!Os fakers agora incluem todas as propriedades obrigatórias das entidades, resolvendo o problema crítico identificado na revisão anterior. A configuração está abrangente e realista.
52-68: LGTM!O método helper
CreateFakerestá bem projetado, permitindo criação flexível de usuários com coleções pré-populadas ou vazias. O padrão de null-coalescing garante que as coleções nunca sejam nulas, alinhando-se com o construtor da entidade User.
70-239: LGTM!Os métodos de teste utilizam corretamente os fakers para geração de dados. O padrão é consistente e os cenários de teste cobrem adequadamente casos de novos usuários, usuários existentes e manipulação de coleções.
240-633: LGTM!Os cenários de teste restantes estão bem estruturados e cobrem casos importantes como prevenção de duplicatas, manipulação de coleções nulas e parâmetros nulos. O uso dos fakers é consistente e correto em todos os métodos. O erro de digitação mencionado na revisão anterior foi corrigido.
InvoiceReminder.Application.UnitTests/AppServices/BaseAppServiceTests.cs (3)
1-1: Ótima adição da biblioteca Bogus!A importação do Bogus e a declaração dos campos faker estão corretas. Isso melhora significativamente a geração de dados de teste, tornando-os mais realistas e variados.
Also applies to: 17-18
45-45: Excelente refatoração para usar dados gerados!A substituição de dados hard-coded por dados gerados via Bogus melhora significativamente a robustez dos testes, permitindo maior variedade de cenários. O uso de
Guid.NewGuid()nos testes de GetByIdAsync também é apropriado para os cenários onde IDs específicos não são necessários.Also applies to: 101-101, 146-146, 168-168, 173-173, 190-190, 213-213, 250-250
285-291: Classes de teste bem estruturadas.As definições de
TestEntityeTestEntityViewModelestão corretas e incluem todas as propriedades necessárias para suportar os fakers do Bogus. O uso desealedé apropriado para classes de teste.Also applies to: 293-299
InvoiceReminder.Application.UnitTests/AppServices/JobScheduleAppServiceTests.cs (6)
1-1: LGTM!A importação do Bogus é apropriada para a nova abordagem de geração de dados de teste.
21-22: LGTM!Boa prática centralizar as expressões cron válidas como campo readonly. Isso facilita a manutenção e reutilização nos testes.
106-106: LGTM!Ótima melhoria na variabilidade dos dados de teste. A substituição de dados hard-coded por geração via Bogus torna o teste mais robusto e realista.
132-136: LGTM!Excelente uso do
RuleForpara sobrescrever oUserIde garantir que todos os 3 registros gerados compartilhem o mesmo ID de usuário. A implementação está correta e clara.
161-161: LGTM!Mudança simples e apropriada, consistente com a abordagem de geração de dados via Bogus adotada no arquivo.
32-42: As expressões cron estão válidas para Quartz.Quartz cron expressions consistem em 6 ou 7 campos separados por espaço, sendo a ordem: segundos, minutos, horas, dia do mês, mês, dia da semana, e ano. Todas as 7 expressões utilizam corretamente 6 campos (o ano é opcional) e seguem a sintaxe válida do Quartz. O caractere '?' é permitido para os campos de dia-do-mês e dia-da-semana e é usado para especificar "nenhum valor específico", o que está correto nas expressões fornecidas. Os nomes de dias da semana em maiúsculas (como "MON") também são suportados.
InvoiceReminder.Application.UnitTests/AppServices/UserAppServiceTests.cs (4)
1-1: Adição do Bogus está correta e alinhada com os objetivos do PR.A importação da biblioteca Bogus e a declaração do campo
_fakerseguem as convenções adequadas para geração de dados de teste.Also applies to: 18-18
26-27: Inicialização do Faker no construtor está correta.A inicialização da instância
Fakerno construtor é apropriada para operações simples de geração de dados.
66-67: Excelente uso do Faker para geração de dados de teste.A substituição de dados codificados por dados gerados via Faker melhora a manutenibilidade dos testes. Derivar o email do usuário gerado garante consistência entre os dados de teste.
92-92: Uso apropriado do Faker para geração de email.A substituição do email codificado por um valor gerado via Faker está correta e melhora a variedade dos dados de teste.
InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs (2)
1-1: Ótima adoção do Bogus para geração de dados de teste!A integração do Bogus melhora significativamente a qualidade dos testes ao gerar dados aleatórios e consistentes. A inicialização do faker em
InitializeFaker()está correta, definindo regras apropriadas paraIdeName. Note queCreatedAteUpdatedAtnão são definidos no faker, o que está correto, pois são atribuídos pelo métodoBulkInsertAsyncvia reflexão.Also applies to: 16-16, 33-33, 44-49
60-60: Substituição consistente de instanciação manual por geração via Faker.A substituição de instanciações manuais de
TestEntitypor_testEntityFaker.Generate()ou_testEntityFaker.Generate(n)está implementada corretamente em todos os testes, proporcionando dados de teste mais variados e realistas.Also applies to: 77-77, 101-101, 119-119, 141-141, 179-179, 203-203
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
InvoiceReminder.Application.UnitTests/AppServices/BaseAppServiceTests.cs (1)
28-40: Excelente! A lógica de geração de datas está correta.A configuração dos fakers garante consistência temporal:
UpdatedAté gerado usandofaker.Date.Between(entity.CreatedAt, DateTime.UtcNow), garantindo queUpdatedAtsempre será maior ou igual aCreatedAt. Isso resolve a preocupação levantada no comentário de revisão anterior.
🧹 Nitpick comments (3)
InvoiceReminder.Application.UnitTests/AppServices/BaseAppServiceTests.cs (1)
167-186: Considere usar o ID da entidade gerada para melhorar a clareza do teste.O teste gera uma entidade na linha 170, mas chama
GetByIdAsynccomGuid.NewGuid()na linha 175. Embora funcionalmente correto (já que o repositório está mockado para retornar a entidade para qualquer Guid), usarentity.Idtornaria o teste mais explícito e fácil de entender.🔎 Refatoração sugerida para melhorar a clareza
// Arrange var entity = _entityFaker.Generate(); _ = _repository.GetByIdAsync(Arg.Any<Guid>(), Arg.Any<CancellationToken>()).Returns(entity); // Act - var result = await _appService.GetByIdAsync(Guid.NewGuid(), TestContext.CancellationToken); + var result = await _appService.GetByIdAsync(entity.Id, TestContext.CancellationToken);InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs (2)
210-211: Considere gerar apenas o nome em vez da entidade completa.Gerar uma entidade completa apenas para obter o valor de
Nameé desnecessário. Você pode usar diretamentenew Faker().Lorem.Word()para maior eficiência.🔎 Refatoração sugerida
- var updatedName = _testEntityFaker.Generate().Name; - entity.Name = updatedName; + entity.Name = new Faker().Lorem.Word();
242-243: Considere gerar apenas o nome em vez da entidade completa.Gerar uma entidade completa apenas para obter o valor de
Nameé desnecessário. Você pode usar diretamentenew Faker().Lorem.Word()para maior eficiência.🔎 Refatoração sugerida
- var updatedName = _testEntityFaker.Generate().Name; - entity.Name = updatedName; + entity.Name = new Faker().Lorem.Word();
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
.github/workflows/workflow-ci.yml(1 hunks)InvoiceReminder.Application.UnitTests/AppServices/BaseAppServiceTests.cs(9 hunks)InvoiceReminder.Application.UnitTests/AppServices/JobScheduleAppServiceTests.cs(6 hunks)InvoiceReminder.Application.UnitTests/AppServices/UserAppServiceTests.cs(4 hunks)InvoiceReminder.DomainEntities.UnitTests/Extensions/UserExtensionsTests.cs(29 hunks)InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs(14 hunks)
🧰 Additional context used
🧬 Code graph analysis (4)
InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs (2)
InvoiceReminder.Application.UnitTests/AppServices/BaseAppServiceTests.cs (1)
TestEntity(287-293)InvoiceReminder.Domain/Extensions/EntityExtensions.cs (1)
Guid(41-52)
InvoiceReminder.Application.UnitTests/AppServices/UserAppServiceTests.cs (2)
InvoiceReminder.DomainEntities.UnitTests/Extensions/UserExtensionsTests.cs (1)
Faker(52-68)InvoiceReminder.Infrastructure.UnitTests/Data/Repository/UserRepositoryTests.cs (1)
Faker(33-41)
InvoiceReminder.Application.UnitTests/AppServices/JobScheduleAppServiceTests.cs (3)
InvoiceReminder.Application.UnitTests/AppServices/UserAppServiceTests.cs (1)
Faker(29-43)InvoiceReminder.Application.UnitTests/AppServices/ScanEmailDefinitionAppServiceTests.cs (1)
Faker(30-42)InvoiceReminder.Domain/Entities/JobSchedule.cs (1)
JobSchedule(3-7)
InvoiceReminder.DomainEntities.UnitTests/Extensions/UserExtensionsTests.cs (4)
InvoiceReminder.Domain/Entities/JobSchedule.cs (1)
JobSchedule(3-7)InvoiceReminder.Domain/Entities/EmailAuthToken.cs (1)
EmailAuthToken(3-12)InvoiceReminder.Domain/Entities/ScanEmailDefinition.cs (1)
ScanEmailDefinition(5-13)InvoiceReminder.Domain/Entities/User.cs (2)
User(3-21)User(14-20)
⏰ 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 (21)
.github/workflows/workflow-ci.yml (1)
25-32: Correção aplicada corretamente! A issue crítica anterior foi resolvida.O uso de
$GITHUB_ENVnas linhas 30-31 garante que as variáveisLANGeLC_ALLpersistam entre os steps subsequentes (restore, build, testes). Esta é a abordagem correta para o GitHub Actions, resolvendo a issue crítica identificada anteriormente ondeexportnão persistiria as variáveis entre steps.A implementação está alinhada com as melhores práticas do GitHub Actions.
InvoiceReminder.Application.UnitTests/AppServices/BaseAppServiceTests.cs (1)
1-1: LGTM! Implementação consistente do Bogus para geração de dados de teste.A introdução do Bogus melhora significativamente a qualidade dos testes ao substituir dados estáticos por dados gerados dinamicamente. A implementação está consistente em todos os métodos de teste, e as entidades de teste foram adequadamente atualizadas com as propriedades necessárias (Id, CreatedAt, UpdatedAt).
Also applies to: 17-18, 47-47, 103-103, 148-148, 170-170, 215-215, 252-252, 287-301
InvoiceReminder.Application.UnitTests/AppServices/JobScheduleAppServiceTests.cs (7)
21-22: LGTM!A declaração dos campos
_fakere_validCronExpressionscomoreadonlyestá correta e segue o padrão adotado em outros arquivos de teste do projeto.
33-41: LGTM!As expressões cron são válidas para o Quartz e os comentários explicativos facilitam a manutenção. Boa prática centralizar essas expressões para reutilização nos testes.
44-52: Correção da geração de datas aplicada corretamente.A lógica de geração de datas foi corrigida conforme sugerido na revisão anterior. Agora
UpdatedAté garantidamente posterior ou igual aCreatedAtusandofaker.Date.Between(j.CreatedAt, DateTime.UtcNow).
54-62: Correção da geração de datas aplicada corretamente.A mesma correção foi aplicada neste método, garantindo que
UpdatedAt >= CreatedAt. A consistência entreCreateJobScheduleFakereCreateJobScheduleViewModelFakerestá adequada.
106-106: LGTM!Uso correto do helper Faker para gerar dados de teste dinâmicos. Melhora a robustez do teste ao validar com dados variados.
132-136: LGTM!Boa abordagem sobrescrever o
UserIdcom.RuleFor(j => j.UserId, userId)após criar o Faker base, garantindo que todos os registros gerados compartilhem o mesmo usuário para o teste.
161-161: LGTM!Uso consistente do
_faker.Random.Guid()para geração de IDs de teste.InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs (3)
44-49: LGTM! Inicialização do Faker segue as melhores práticas.A configuração do Faker está correta e segue as convenções da biblioteca Bogus. As regras para
IdeNamesão apropriadas para geração de dados de teste, e a chamada emSetupgarante o isolamento entre testes.
60-60: LGTM! Uso consistente do Faker para geração de dados de teste.A substituição de entidades hard-coded por dados gerados via Faker melhora a manutenibilidade e a qualidade dos testes. A implementação é consistente em todos os métodos de teste e não apresenta problemas de mutação de estado.
Also applies to: 77-77, 101-101, 119-119, 141-141, 179-179, 203-203, 232-232
264-273: LGTM! A questão de mutação de estado foi corrigida.A implementação agora segue a abordagem recomendada no comentário de revisão anterior: gera as entidades primeiro e depois define a propriedade
Namediretamente, evitando a mutação do faker compartilhado. Excelente correção!InvoiceReminder.Application.UnitTests/AppServices/UserAppServiceTests.cs (5)
1-1: LGTM!A adição da diretiva
using Bogusé apropriada e necessária para suportar a geração de dados de teste com Faker introduzida neste arquivo.
18-18: LGTM!A declaração e inicialização do campo
_fakerestão corretas. O uso comoreadonlyé uma boa prática e a instância é apropriada para geração simples de dados de teste.Also applies to: 26-27
29-43: LGTM!O método
CreateFaker()está bem implementado e segue os padrões estabelecidos em outros arquivos de teste do projeto. A configuração de todas as propriedades doUsercom regras apropriadas do Faker melhora a qualidade e manutenibilidade dos testes.Nota: A issue anterior sobre a duplicação da regra
UpdatedAtfoi resolvida - o código atual define essa propriedade apenas uma vez na linha 38.
65-66: LGTM!A mudança para usar
CreateFaker().Generate()melhora a qualidade do teste ao utilizar dados gerados de forma consistente, em vez de dados codificados manualmente.
91-91: LGTM!O uso de
_faker.Internet.Email()é apropriado para este teste de cenário negativo, gerando um email aleatório que não deve existir no repositório.InvoiceReminder.DomainEntities.UnitTests/Extensions/UserExtensionsTests.cs (4)
1-3: Importações apropriadas para suporte a Bogus.As importações de
BoguseInvoiceReminder.Domain.Enumssão adequadas para a geração de dados de teste utilizando fakers e para referenciar o enumInvoiceType.
12-50: Excelente implementação dos fakers com todas as propriedades obrigatórias configuradas!Os fakers agora estão completamente configurados com todas as propriedades obrigatórias das entidades, resolvendo o problema crítico apontado em revisões anteriores. Cada faker inclui:
- Invoice: UserId, Bank, Beneficiary, Amount, Barcode, DueDate (44 dígitos para código de barras é apropriado)
- JobSchedule: UserId, CronExpression (formato de cron válido)
- EmailAuthToken: UserId, AccessToken, RefreshToken, NonceValue, TokenProvider, AccessTokenExpiry
- ScanEmailDefinition: UserId, InvoiceType, Beneficiary, Description, SenderEmailAddress, AttachmentFileName
A geração de dados é realista e utiliza os métodos apropriados do Bogus (Finance, Company, Internet, System, etc.). O uso de
.ToUniversalTime()nas datas garante consistência.
52-68: Helper CreateFaker bem projetado para flexibilidade nos testes.O método
CreateFakerestá bem estruturado, permitindo criar usuários com coleções pré-populadas opcionalmente. O uso de parâmetros opcionais com valores padrão e o operador de coalescência nula (??) para inicializar coleções vazias proporcionam flexibilidade aos testes, possibilitando cenários tanto com coleções vazias quanto pré-populadas.
70-634: Cobertura de testes abrangente com uso consistente de fakers.Os métodos de teste estão bem estruturados e cobrem cenários diversos:
- Criação de novos usuários com e sem entidades relacionadas
- Adição de itens a usuários existentes
- Prevenção de duplicatas
- Tratamento de coleções vazias e nulas
- Validação de parâmetros nulos
O uso consistente dos fakers melhora a qualidade dos dados de teste, tornando-os mais realistas e reduzindo a manutenção. O padrão Arrange-Act-Assert é seguido consistentemente.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs (1)
241-241: Aplique a mesma otimização sugerida na linha 210.Esta linha tem o mesmo problema de eficiência da linha 210 ao criar uma nova instância de
Faker(). Considere usar uma das alternativas sugeridas anteriormente para manter a consistência.
🧹 Nitpick comments (1)
InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs (1)
210-210: Considere reutilizar o faker compartilhado ou usar string literal.Criar uma nova instância de
Faker()apenas para gerar um nome é ineficiente. Além disso,Name.FullName()gera strings potencialmente mais longas que oLorem.Word()usado na inicialização, o que pode causar inconsistências se houver restrições de tamanho no campoName.🔎 Alternativas sugeridas
Alternativa 1: Usar string literal para maior clareza
- entity.Name = new Faker().Name.FullName(); + entity.Name = "UpdatedName";Alternativa 2: Usar o faker compartilhado
- entity.Name = new Faker().Name.FullName(); + entity.Name = _testEntityFaker.Generate().Name;Alternativa 3: Criar faker estático para nomes
No início da classe:
private static readonly Faker _faker = new();No teste:
- entity.Name = new Faker().Name.FullName(); + entity.Name = _faker.Lorem.Word();
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
InvoiceReminder.Application.UnitTests/AppServices/BaseAppServiceTests.cs(9 hunks)InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs(14 hunks)
⏰ 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 (10)
InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs (6)
1-16: Boa adição do Bogus para geração de dados de teste.A importação do Bogus e a declaração do campo
_testEntityFakerseguem o padrão recomendado para geração de dados de teste. A abordagem de usar uma instância compartilhada do faker é apropriada para este cenário.
33-33: Inicialização adequada do faker no setup do teste.A chamada a
InitializeFaker()no métodoSetupgarante que o faker seja configurado corretamente antes de cada teste, evitando contaminação de estado entre testes.
44-49: Método de inicialização bem estruturado.O método
InitializeFaker()centraliza a configuração das regras do Faker, tornando a manutenção mais fácil e garantindo consistência na geração de dados de teste.
60-60: Uso correto do faker para geração de entidade única.A substituição da criação manual por
_testEntityFaker.Generate()melhora a manutenibilidade e consistência dos dados de teste.
77-77: Geração eficiente de múltiplas entidades.O uso de
_testEntityFaker.Generate(2)é uma forma limpa e eficiente de criar múltiplas entidades de teste com dados aleatórios.
262-271: Excelente resolução do problema de mutação do faker compartilhado.A implementação atual aborda corretamente a preocupação levantada no comentário de revisão anterior. Ao gerar as entidades primeiro com
_testEntityFaker.Generate()e depois definir a propriedadeNameindividualmente, você evita mutar as regras do faker compartilhado, garantindo que outros testes não sejam afetados.Esta é exatamente a Solução 1 recomendada na revisão anterior.
InvoiceReminder.Application.UnitTests/AppServices/BaseAppServiceTests.cs (4)
1-1: LGTM! Integração do Bogus para geração de dados de teste.A introdução da biblioteca Bogus melhora significativamente a qualidade dos testes ao substituir dados codificados manualmente por dados gerados dinamicamente, aumentando a cobertura de cenários de teste.
Also applies to: 17-18
28-40: Excelente! Correção da lógica de datas aplicada conforme sugerido.A configuração dos fakers agora garante consistência temporal:
UpdatedAté gerado usandofaker.Date.Between(entity.CreatedAt, DateTime.UtcNow), assegurando que sempre será maior ou igual aCreatedAt. Isso resolve o problema identificado na revisão anterior.
47-47: LGTM! Uso apropriado dos fakers nos métodos de teste.A substituição de dados codificados manualmente por dados gerados via Bogus está implementada corretamente em todos os testes. Destaque para:
- Uso adequado de
.Generate()e.Generate(count)conforme necessário- Linha 175: Uso correto de
entity.Iddo objeto gerado- Linha 192: Uso apropriado de
Guid.NewGuid()para o cenário de "entidade não encontrada"Also applies to: 103-103, 148-148, 170-170, 175-175, 192-193, 215-215, 252-252
287-293: LGTM! Definições das classes de teste atualizadas adequadamente.As classes
TestEntityeTestEntityViewModelforam corretamente atualizadas comopublic sealedcom as propriedades necessárias (Id,CreatedAt,UpdatedAt) para suportar a geração de dados via Bogus. A estrutura espelhada entre entidade e view model mantém consistência nos testes.Also applies to: 295-301
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs (1)
210-210: Considere gerar apenas o nome para melhor eficiência.O padrão
_testEntityFaker.Generate().Namegera uma entidade completa apenas para extrair a propriedadeName. Embora funcional e o overhead seja negligenciável em testes, você poderia criar um método auxiliar ou usarnew Faker().Lorem.Word()diretamente para maior clareza de intenção.🔎 Refatoração opcional
Adicione um método auxiliar na classe ou use Faker diretamente:
- entity.Name = _testEntityFaker.Generate().Name; + entity.Name = new Faker().Lorem.Word();Ou crie um método auxiliar:
private string GenerateRandomName() => new Faker().Lorem.Word();E use:
- entity.Name = _testEntityFaker.Generate().Name; + entity.Name = GenerateRandomName();Also applies to: 241-241
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs(14 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs (3)
InvoiceReminder.Application.UnitTests/AppServices/BaseAppServiceTests.cs (1)
TestEntity(287-293)InvoiceReminder.Domain/Extensions/EntityExtensions.cs (1)
Guid(41-52)InvoiceReminder.Data/Repository/BaseRepository.cs (5)
BaseRepository(8-94)BaseRepository(15-20)Task(22-27)Task(29-40)Task(52-55)
⏰ 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 (4)
InvoiceReminder.Infrastructure.UnitTests/Data/Repository/BaseRepositoryTests.cs (4)
1-1: LGTM! Integração do Bogus está bem estruturada.A importação do Bogus e a declaração do campo
_testEntityFakerestão corretas. A inicialização por teste garante isolamento entre os testes.Also applies to: 16-16
33-33: LGTM! Inicialização do Faker está apropriada.A configuração do Faker com
Guid.NewGuid()para Id eLorem.Word()para Name é adequada para geração de dados de teste. A inicialização noTestInitializegarante que cada teste comece com um Faker limpo.Also applies to: 44-49
60-60: LGTM! Uso consistente do Faker para geração de entidades.As chamadas
_testEntityFaker.Generate()e_testEntityFaker.Generate(n)substituem adequadamente as inicializações inline anteriores, tornando os testes mais concisos e mantendo a geração de dados centralizada.Also applies to: 77-77, 101-101, 119-119, 141-141, 179-179, 203-203, 231-231
262-271: Excelente! O problema anterior foi corrigido.O código agora gera as entidades primeiro com
_testEntityFaker.Generate()e depois atribui os valores deNameindividualmente, evitando a mutação do faker compartilhado comRuleFor. Esta é exatamente a abordagem recomendada no comentário de revisão anterior.
1 participant
Updates .NET packages to their latest versions, including
essential libraries and testing dependencies.
This ensures the project benefits from the newest features,
security patches, and performance improvements.
Includes updates to bulk extensions library.
Adds global.json to define the .NET SDK version, also
adds bogus package to mock data for unit tests and improve
testing data generation.
Removes
MaxCpuCountsetting fromCodeCoverage.runsettings.Summary by CodeRabbit
Chores
Refactor
Tests
✏️ Tip: You can customize this high-level summary in your review settings.