Fix naming in handler and tests#241
Conversation
…epository for consistency
Skiper29
requested review from
Markian-Grybok,
denys-pavskyi,
oleksandrhofner and
weazy12
WalkthroughRenames Favorite→Favourite across handler and tests, updating repository property references and the entity’s namespace/type to DAL.Entities.Favourite.FavouriteStreetcode. No control-flow or business-logic changes. Changes
Sequence Diagram(s)Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests
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: 1
🧹 Nitpick comments (2)
Streetcode/Streetcode.BLL/MediatR/Streetcode/Streetcode/CreateFavourite/CreateFavouriteStreetcodeHandler.cs (2)
51-55: Entity construction updated to the new type.Optional: since the namespace is already imported, you can drop the fully-qualified name for brevity.
- var favouriteStreetcode = new DAL.Entities.Favourite.FavouriteStreetcode + var favouriteStreetcode = new FavouriteStreetcode
31-42: Consider hardening claims parsing (optional).Using int.Parse can throw; guarding null User/Claims would avoid exceptions in edge cases.
- var userIdString = _httpContextAccessor.HttpContext?.User.Claims + var userIdString = _httpContextAccessor.HttpContext?.User?.Claims .FirstOrDefault(c => c.Type == ClaimTypes.NameIdentifier)?.Value; - var userId = int.Parse(userIdString); + if (!int.TryParse(userIdString, out var userId)) + { + var errorMsg = Errors_Jwt.UserNotFound; + _logger.LogError(request, errorMsg); + return Result.Fail(errorMsg); + }Note: updating this would require adjusting the test that currently expects ArgumentNullException when Claims is null.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
Streetcode/Streetcode.BLL/MediatR/Streetcode/Streetcode/CreateFavourite/CreateFavouriteStreetcodeHandler.cs(1 hunks)Streetcode/Streetcode.XUnitTest/BLL/MediatR/StreetCode/Streetcode/CreateFavourite/CreateFavouriteStreetcodeHandlerTests.cs(11 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
Streetcode/Streetcode.BLL/MediatR/Streetcode/Streetcode/CreateFavourite/CreateFavouriteStreetcodeHandler.cs (2)
Streetcode/Streetcode.BLL/Util/Extensions/ResourceExtensions.cs (1)
FormatWith(5-8)Streetcode/Streetcode.BLL/Services/Logging/LoggerService.cs (1)
LogError(35-40)
⏰ 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: Build and analyze
🔇 Additional comments (16)
Streetcode/Streetcode.XUnitTest/BLL/MediatR/StreetCode/Streetcode/CreateFavourite/CreateFavouriteStreetcodeHandlerTests.cs (14)
16-17: Alias introduction is clear and consistent.Keeps generics readable and unifies type usage across tests.
35-36: Repository property rename wired correctly.Mocks now target FavouriteStreetcodeRepository as intended.
53-56: Updated repository method setup matches new type.Generics now use FavouriteStreetcodeEntity; setup looks correct.
64-65: CreateAsync verification updated to new type.Argument predicate matches expected user and streetcode IDs.
81-81: No creation when HttpContext is null — verification OK.
95-95: No creation when claims are null — verification OK.
132-132: Existing favourite instantiation uses the alias — OK.
136-138: GetFirstOrDefaultAsync setup generics updated — OK.
145-145: CreateAsync not called when favourite exists — verification OK.
158-161: Null-return setup for absence of favourite — OK.
169-169: CreateAsync called once on failure path — verification OK.
183-186: No-existing-favourite setup uses alias — OK.
204-207: Parameterized setup with alias — OK.
213-216: Expression verification compiles against alias — OK.Streetcode/Streetcode.BLL/MediatR/Streetcode/Streetcode/CreateFavourite/CreateFavouriteStreetcodeHandler.cs (2)
43-49: Repository property rename usage is correct.Duplicate check now calls FavouriteStreetcodeRepository consistently.
57-58: Create and save flow remains unchanged and correct.CreateAsync on the renamed repo followed by SaveChangesAsync is consistent.
|
My bad. Sorry about that. |
4 participants
dev
Code reviewers
Summary of issue
Summary of change
This pull request standardizes the naming of the "FavouriteStreetcode" entity and related repository across both the application logic and unit tests. It replaces the inconsistent "FavoriteStreetcode" naming with the correct "FavouriteStreetcode" spelling throughout the codebase, ensuring consistency and reducing the risk of errors.
CHECK LIST
Summary by CodeRabbit
No user-facing changes in this release.