Add TicketController integration test suite - #44
Conversation
…on in `TicketControllerIT`
…points in `TicketControllerIT`
…tions in `TicketControllerIT`
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 39 minutes and 40 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughA new Spring Boot integration test suite for Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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.
🧹 Nitpick comments (2)
src/test/java/org/example/alfs/controllers/TicketControllerIT.java (2)
84-100: Minor: reuse the seeded ticket instead of creating another.
setUp()already creates a ticket and storesticketId; this test builds a second one solely to obtain a token. You can fetch the existing ticket's token via the service/repository and drop the duplication, keeping tests lean and focused.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/test/java/org/example/alfs/controllers/TicketControllerIT.java` around lines 84 - 100, In anonymousReporter_validToken_returnsView() remove the extra ticket creation and instead fetch the seeded ticket's token created in setUp() (use the stored ticketId from the test class) by calling ticketService.findById(ticketId) or repository equivalent, then use that ticket.getToken() in the mockMvc.perform(get("/tickets/token/" + ...)); update references in the test to use ticketId and existing ticket retrieval so you no longer call ticketService.createNewTicket(dto).
206-214: Make the "invalid transition" precondition explicit.This test depends on the ticket being in
OPEN(no investigator) so thatOPEN → RESOLVEDis rejected, which works only because@Transactionalrolls back state between tests and the prioradmin_canUpdateTicketStatustest'sassignInvestigatorcall doesn't leak here. Consider asserting or arranging the starting status explicitly (or using a status pair that is unambiguously invalid regardless of transitions map, e.g.RESOLVED → OPENon a freshly resolved ticket) so the intent and precondition are self-documenting and robust to future changes inALLOWED_TRANSITIONS.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/test/java/org/example/alfs/controllers/TicketControllerIT.java` around lines 206 - 214, The test admin_cannotPerformInvalidStatusTransition relies on implicit state; make the precondition explicit by ensuring the ticket is in the expected starting status before performing the POST: either reset or fetch the ticket and assert/set its status to OPEN (and confirm no investigator assigned) or explicitly transition it into a state that will unambiguously reject the requested change (e.g., programmatically set to RESOLVED then attempt RESOLVED→OPEN) so the invalid-transition intent is clear; modify the setup inside TicketControllerIT (or this test) to arrange/assert the ticket's status (using existing helpers like assignInvestigator or status setters used in admin_canUpdateTicketStatus) prior to calling mockMvc.perform in admin_cannotPerformInvalidStatusTransition.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@src/test/java/org/example/alfs/controllers/TicketControllerIT.java`:
- Around line 84-100: In anonymousReporter_validToken_returnsView() remove the
extra ticket creation and instead fetch the seeded ticket's token created in
setUp() (use the stored ticketId from the test class) by calling
ticketService.findById(ticketId) or repository equivalent, then use that
ticket.getToken() in the mockMvc.perform(get("/tickets/token/" + ...)); update
references in the test to use ticketId and existing ticket retrieval so you no
longer call ticketService.createNewTicket(dto).
- Around line 206-214: The test admin_cannotPerformInvalidStatusTransition
relies on implicit state; make the precondition explicit by ensuring the ticket
is in the expected starting status before performing the POST: either reset or
fetch the ticket and assert/set its status to OPEN (and confirm no investigator
assigned) or explicitly transition it into a state that will unambiguously
reject the requested change (e.g., programmatically set to RESOLVED then attempt
RESOLVED→OPEN) so the invalid-transition intent is clear; modify the setup
inside TicketControllerIT (or this test) to arrange/assert the ticket's status
(using existing helpers like assignInvestigator or status setters used in
admin_canUpdateTicketStatus) prior to calling mockMvc.perform in
admin_cannotPerformInvalidStatusTransition.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 39a7c27f-36e0-4cfa-8023-acb94e496bc4
📒 Files selected for processing (1)
src/test/java/org/example/alfs/controllers/TicketControllerIT.java
…zation in `TicketControllerIT`
…ition test in `TicketControllerIT`
Summary by CodeRabbit