feature: add JUnit 5 + Mockito unit tests for BankController

[devin-ai-integration]

Summary

Adds BankControllerTest — fast, isolated unit tests for every public handler in BankController, with no Spring context, DB, or network. Uses @ExtendWith(MockitoExtension.class), @Mock AccountService, @InjectMocks BankController. No production code changed; no new dependencies (uses existing spring-boot-starter-test + spring-security-test).

Each handler is covered with a happy path plus the relevant error/branch paths:

• dashboard / deposit / transactionHistory — resolve username from SecurityContextHolder, call accountService, assert view name + model attributes.
• registerAccount, withdraw, transferAmount — both the success redirect and the RuntimeException branch (asserts error/account model attributes equal the exact exception message and dashboard/register view).
• showRegistrationForm / login — static view names, verifyNoInteractions(accountService).

SecurityContext-dependent tests set a real SecurityContextImpl with a TestingAuthenticationToken in a helper and clear it in @AfterEach. A real lightweight ExtendedModelMap is used instead of mocking Model. AccountService interactions are asserted with verify(...) (and never() where a branch should skip a call).

@Test
void withdrawOnRuntimeExceptionAddsErrorAndAccountAndReturnsDashboardView() {
    doThrow(new RuntimeException("Insufficient funds")).when(accountService).withdraw(account, amount);
    String view = controller.withdraw(amount, model);
    assertEquals("dashboard", view);
    assertEquals("Insufficient funds", model.getAttribute("error"));
    assertSame(account, model.getAttribute("account"));
}

Validation

./mvnw -Dtest=BankControllerTest test → Tests run: 12, Failures: 0, Errors: 0, Skipped: 0. Run in isolation to avoid the existing DB-backed contextLoads test.

Link to Devin session: https://app.devin.ai/sessions/faf31d9c984d4946b2e6f20f49e1d231
Requested by: @matthewguerra-cog

---

Devin Review

Status	Commit
🟢 Reviewed	fe4d323

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[staging-devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

Debug

Playground

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

🚩 Tests don't cover negative/zero amount edge cases

The tests only cover happy-path amounts and the RuntimeException paths that the controller already handles. There are no tests for edge cases like negative amounts (new BigDecimal("-50")) or zero amounts (BigDecimal.ZERO) passed to deposit, withdraw, or transferAmount. The controller delegates directly to AccountService without validating these inputs, and AccountService itself only checks for insufficient funds — it doesn't reject negative or zero amounts. This means a user could deposit a negative amount and reduce their balance, or transfer a negative amount and effectively steal funds from the recipient. While this is a pre-existing issue in the production code (AccountService.java:51-62, AccountService.java:103-135), the new tests could have caught this gap.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Thanks — agreed this is a real gap, but it's a validation gap in production code (AccountService accepts negative/zero amounts), not a defect in these tests. This PR's scope is mock-only unit tests for BankController, which delegates straight to AccountService without validating amounts, so the controller has no negative/zero-amount branch to assert against. Adding such tests would either (a) just document the current unsafe behavior, or (b) require changing production code, which is explicitly out of scope here (don't modify production code to satisfy a test).

I'm leaving the production behavior unchanged and flagging the underlying vulnerability separately. If you'd like, I can open a follow-up PR that adds amount validation in AccountService.deposit/withdraw/transferAmount plus the corresponding negative/zero-amount tests.