Skip to content

[Tests] Add unit tests for BootstrapContext, IllegalSlotAssignmentException, TableVersionHistoryDAO, MutexDAO#35

Open
DiamondDagger590 wants to merge 1 commit into
developfrom
claude/stoic-cori-h4r0p6
Open

[Tests] Add unit tests for BootstrapContext, IllegalSlotAssignmentException, TableVersionHistoryDAO, MutexDAO#35
DiamondDagger590 wants to merge 1 commit into
developfrom
claude/stoic-cori-h4r0p6

Conversation

@DiamondDagger590

@DiamondDagger590 DiamondDagger590 commented Jun 12, 2026

Copy link
Copy Markdown
Owner

Summary

  • BootstrapContextTest: Tests record accessors (plugin(), startupProfile()), record equality with same/different plugins/profiles, hashCode consistency, and toString representation (0% → 100% line coverage, 1/1 line)
  • IllegalSlotAssignmentExceptionTest: Tests constructor field storage, getGui()/getSlot() accessors, getMessage() format containing GUI and slot details, RuntimeException inheritance, and null cause verification (0% → 100% line coverage, 7/7 lines)
  • TableVersionHistoryDAOTest: Tests getLatestVersion() for stored version, missing table (returns 0), SQL exception handling, and multi-row iteration; setTableVersion() success/failure paths; attemptCreateTable() when table exists vs doesn't exist vs SQL exception; updateTable() from version 0→1 and no-op when current/above current (0% → 97.4% line coverage, 37/38 lines; remaining 1 line is the class declaration)
  • MutexDAOTest: Tests attemptCreateTable() when table exists vs creation vs SQL exception; updateTable() from version 0→1 and no-op when current; isUserMutexLocked() for locked/unlocked/missing/exception cases; updateUserMutex(CorePlayer) for locked/unlocked/exception paths; updateUserMutex(UUID, boolean) for lock/unlock/exception paths (0% → 97.7% line coverage, 42/43 lines; remaining 1 line is the class declaration)

Infrastructure change

Added Mockito 5.14.2 as a testImplementation dependency to enable mocking JDBC components (Connection, PreparedStatement, ResultSet), Database, CorePlugin, BaseGui, Slot, and CorePlayer for testing classes that depend on framework types.

Classes covered (avoiding PR #27, PR #30, PR #31, PR #32, PR #33, and PR #34 overlap)

PR #27 covers GetItemRequest, StatisticEntry, ReloadableContent, ReloadableContentManager, StartupProfile. PR #30 covers RegistryAccess, StatisticModifyEvent, PostStatisticModifyEvent, Transaction. PR #31 covers database events, GUI events, SQLiteDatabaseDriver, DatabaseDriver, ManagerKey/PluginHookKey constants. PR #32 covers player events, CorePlayer, Credentials, ConnectionDetails, CorePlayerOfflineException. PR #33 covers PlayerStatisticData, ReloadableParser, ItemPluginType, ChainPlayerContextFilter. PR #34 covers BatchTransaction, FailSafeTransaction, ItemBuilderConfigurationKeys, RegistryKeyImpl. This PR targets entirely different classes with no overlap.

Coverage impact

4 classes improved: 2 brought from 0% to 100%, 2 brought from 0% to ~97.7%. Overall project coverage: 31.9% → 34.2% (+2.3pp, 94 new lines covered).

Test plan

  • All 664 tests pass via ./gradlew test
  • JaCoCo coverage report confirms expected coverage on all 4 targeted classes
  • No existing tests broken by these additions
  • No production code changes — test-only PR (plus Mockito dependency addition)

https://claude.ai/code/session_0183JW46S7Paz6fmccowQB3S


Generated by Claude Code

Summary by CodeRabbit

  • Tests
    • Added comprehensive test coverage for BootstrapContext, MutexDAO, TableVersionHistoryDAO, and IllegalSlotAssignmentException classes with Mockito-based unit tests.
    • Integrated Mockito test framework dependencies to support mock-based testing.

@coderabbitai

coderabbitai Bot commented Jun 12, 2026

Copy link
Copy Markdown

Review Change Stack

Walkthrough

This PR adds comprehensive test coverage for four domain classes by introducing Mockito as a test dependency and creating four new test suites with nested test classes covering accessors, persistence operations, state transitions, and exception behavior.

Changes

Test Coverage Expansion

Layer / File(s) Summary
Mockito dependency setup
build.gradle.kts
Gradle adds Mockito Core and JUnit Jupiter integration as test dependencies using a centralized version variable.
BootstrapContext test coverage
src/test/java/com/diamonddagger590/mccore/bootstrap/BootstrapContextTest.java
Tests verify plugin and startup profile accessors, equality across contexts with matching/differing plugins and profiles, hash code consistency for equal instances, and toString() output.
MutexDAO test suite
src/test/java/com/diamonddagger590/mccore/database/table/impl/MutexDAOTest.java
Nested test classes cover table creation detection, version upgrades, mutex lock/unlock state queries and updates, with mocked JDBC components and exception handling.
TableVersionHistoryDAO test suite
src/test/java/com/diamonddagger590/mccore/database/table/impl/TableVersionHistoryDAOTest.java
Nested test classes verify version retrieval, persistence, conditional table creation, and upgrade paths using mocked JDBC and database interactions.
IllegalSlotAssignmentException test coverage
src/test/java/com/diamonddagger590/mccore/exception/gui/IllegalSlotAssignmentExceptionTest.java
Tests verify accessor correctness, inheritance relationship, message formatting with GUI and slot details, and that no cause is set.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and specifically summarizes the main change: adding unit tests for four named classes with comprehensive test coverage.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch claude/stoic-cori-h4r0p6

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@github-actions

Copy link
Copy Markdown

Extensibility Review

Breaking change risk: NONE — This diff adds only test infrastructure (Mockito dependencies and new test classes); no production source files are modified.

No extensibility concerns found.

The entire diff consists of:

  1. Two testImplementation-scoped Mockito dependencies in build.gradle.kts — these are never exposed on the compile or runtime classpath of downstream consumers.
  2. Three new test classes (BootstrapContextTest, MutexDAOTest, TableVersionHistoryDAOTest, IllegalSlotAssignmentExceptionTest) under src/test/java — test sources are never packaged into the published artifact and impose no contract obligations on plugin authors.

No public API surfaces, abstract classes, interfaces, method signatures, registry keys, @Deprecated symbols, GUI framework types, or database migration chains are touched. Binary and source compatibility for all downstream plugins is completely unaffected.

@github-actions

Copy link
Copy Markdown

Testing Review

I'll systematically apply every checklist item to the diff.


Findings


CONCERN: BootstrapContextTest method names do not follow the givenContext_whenAction_thenOutcome naming convention.
WHY: Structural problem — the convention is a hard requirement per the framework test quality checklist. Methods are named pluginAccessor, startupProfileAccessor, prodProfileAccessor, equalContexts, differentProfiles, differentPlugins, hashCodeConsistency, toStringContainsClassName. None follow givenX_whenY_thenZ.
WHERE: src/test/java/com/diamonddagger590/mccore/bootstrap/BootstrapContextTest.java


CONCERN: MutexDAOTest method names do not follow the givenContext_whenAction_thenOutcome naming convention.
WHY: Structural problem — methods are named returnsFalseWhenTableExists, returnsTrueWhenTableCreated, returnsFalseOnSqlException, etc. throughout all nested classes. None follow the required convention.
WHERE: src/test/java/com/diamonddagger590/mccore/database/table/impl/MutexDAOTest.java


CONCERN: TableVersionHistoryDAOTest method names do not follow the givenContext_whenAction_thenOutcome naming convention.
WHY: Structural problem — same pattern as above. Methods are named returnsStoredVersion, returnsZeroForMissingTable, returnsZeroOnSqlException, etc.
WHERE: src/test/java/com/diamonddagger590/mccore/database/table/impl/TableVersionHistoryDAOTest.java


CONCERN: IllegalSlotAssignmentExceptionTest method names do not follow the givenContext_whenAction_thenOutcome naming convention.
WHY: Structural problem — methods are named getGuiReturnsGui, getSlotReturnsSlot, getMessageContainsDetails, extendsRuntimeException, noCauseSet, messageFormat. None follow the required convention.
WHERE: src/test/java/com/diamonddagger590/mccore/exception/gui/IllegalSlotAssignmentExceptionTest.java


CONCERN: toStringContainsClassName uses assertEquals(true, ...) instead of assertTrue(...), but more critically the assertion on toString() only verifies the class name string "BootstrapContext" is present — it does not verify that plugin or profile information is present in the output, making the test nearly vacuous.
WHY: Coverage gap — toString() on a record/data class typically includes field values. If the implementation omits field values from toString(), this test will not catch it. The assertion str.contains("BootstrapContext") passes trivially for any non-null string returned by a correctly named class.
WHERE: src/test/java/com/diamonddagger590/mccore/bootstrap/BootstrapContextTest.javatoStringContainsClassName


CONCERN: MutexDAO.updateTable migration path — the "updates from version 0 to 1" test (updatesFromVersion0To1) only verifies that setTableVersion is called with the correct arguments but never verifies that intermediate DDL migration statements (e.g., ALTER TABLE, column additions) between version 0 and version 1 are actually executed.
WHY: Coverage gap — per the checklist, UpdateTableFunction migrations must be verified on both a fresh schema and an already-migrated schema. The test confirms the version-tracking write but not the actual schema change SQL. If the migration body is a no-op or broken, the test still passes.
WHERE: src/test/java/com/diamonddagger590/mccore/database/table/impl/MutexDAOTest.javaUpdateTable.updatesFromVersion0To1


CONCERN: TableVersionHistoryDAO.updateTable migration path — same structural gap as MutexDAOTest. The updatesFromVersion0To1 test verifies the version-tracking write but not any DDL executed during the migration.
WHY: Coverage gap — if the updateTable implementation performs schema-altering SQL before calling setTableVersion, there is no verification that those statements are issued.
WHERE: src/test/java/com/diamonddagger590/mccore/database/table/impl/TableVersionHistoryDAOTest.javaUpdateTable.updatesFromVersion0To1


CONCERN: Neither MutexDAOTest.UpdateTable nor TableVersionHistoryDAOTest.UpdateTable tests cover the scenario where the version is at n-1 (one behind current) to confirm correct incremental migration behavior — only version 0 → 1 and "already current" are tested.
WHY: Coverage gap — if the DAO has multiple migration steps (e.g., 1 → 2, 2 → 3), an intermediate version being partially migrated is not exercised. This is relevant even with a single current version of 1, because the logic path for currentVersion < latestVersion should be explicitly verified to not double-apply.
WHERE: src/test/java/com/diamonddagger590/mccore/database/table/impl/MutexDAOTest.java, src/test/java/com/diamonddagger590/mccore/database/table/impl/TableVersionHistoryDAOTest.java


CONCERN: MutexDAOTest.UpdateUserMutexWithCorePlayer.returnsFalseOnSqlException calls MutexDAO.updateUserMutex(mockConnection, mockCorePlayer) without stubbing mockCorePlayer.getUUID() or mockCorePlayer.isLocked(). The exception is thrown from prepareStatement, which occurs before those calls — but if the implementation ever reorders to call getUUID() first, Mockito strict-stub mode will throw an UnnecessaryStubbingException or the test will fail with an NPE. More critically, the test does not stub mockCorePlayer at all, meaning if the production code calls mockCorePlayer.getUUID() before prepareStatement, the test returns a null UUID silently.
WHY: Structural problem — the test's correctness depends on undocumented internal ordering of the production method. It should either stub all CorePlayer interactions or use lenient() stubs explicitly, and the test comment should justify the assumption.
WHERE: src/test/java/com/diamonddagger590/mccore/database/table/impl/MutexDAOTest.javaUpdateUserMutexWithCorePlayer.returnsFalseOnSqlException


CONCERN: IllegalSlotAssignmentExceptionTest mocks BaseGui<?> and Slot<?> using Mockito, but no Bukkit API is involved in IllegalSlotAssignmentException itself — it is a pure Java exception. However, if BaseGui or Slot extend or tightly depend on Bukkit classes, Mockito mocking them without MockBukkit present may fail at classloading time, or conversely may succeed but hide that a real BaseGui implementation cannot be constructed without Bukkit. The test does not demonstrate the exception being thrown from actual GUI slot assignment code paths.
WHY: Coverage gap — there is no test verifying that IllegalSlotAssignmentException is actually thrown when a slot assignment is attempted on an incompatible GUI. The tests only cover the exception object's accessors in isolation, not the throw site.
WHERE: src/test/java/com/diamonddagger590/mccore/exception/gui/IllegalSlotAssignmentExceptionTest.java


CONCERN: No tests are added for BaseGui, PaginatedGui, or Slot slot population, pagination boundaries (empty page, last page), or click handling, even though IllegalSlotAssignmentExceptionTest implies that GUI/slot logic is part of this diff's scope.
WHY: Coverage gap per checklist — any change touching BaseGui, PaginatedGui, or Slot requires tests for slot population, pagination boundaries, and click handling. If these classes were modified in the production side of this diff (not shown), they have zero corresponding behavioral tests.
WHERE: No test file present for BaseGui, PaginatedGui, or Slot


CONCERN: MutexDAOTest.UpdateTable.noUpdateWhenCurrent and TableVersionHistoryDAOTest.UpdateTable.noUpdateWhenCurrent only assert that setString(1, "player_mutex") / setString(1, "table_history") was called via verify. There is no assertion or verification that setTableVersion (the update path) was not called. A production implementation that always writes the version would pass this test.
WHY: Structural problem — the "no update" scenario must assert absence of the write path, not just presence of the read path. Without a verify(mockStatement, never()).executeUpdate() or equivalent, the test cannot confirm that the "already current" branch suppresses the migration.
WHERE: src/test/java/com/diamonddagger590/mccore/database/table/impl/MutexDAOTest.javaUpdateTable.noUpdateWhenCurrent; src/test/java/com/diamonddagger590/mccore/database/table/impl/TableVersionHistoryDAOTest.javaUpdateTable.noUpdateWhenCurrent and noUpdateWhenAboveCurrent


CONCERN: TableVersionHistoryDAO.getLatestVersion — no test covers a null or empty string table name being passed.
WHY: Coverage gap — the checklist requires null/empty input edge cases for non-trivial public methods. getLatestVersion(Connection, String) has no null-guard tests.
WHERE: src/test/java/com/diamonddagger590/mccore/database/table/impl/TableVersionHistoryDAOTest.javaGetLatestVersion nested class


CONCERN: MutexDAO.isUserMutexLocked — no test covers a null UUID being passed.
WHY: Coverage gap — per checklist, null inputs must be tested for public methods. isUserMutexLocked(Connection, UUID) has no null UUID test.
WHERE: src/test/java/com/diamonddagger590/mccore/database/table/impl/MutexDAOTest.javaIsUserMutexLocked nested class


CONCERN: MutexDAO.updateUserMutex(Connection, UUID, boolean)returnsFalseWhenUnlocking asserts assertFalse(result) where result is the return value of updateUserMutex with locked=false. If the method's contract is "returns the mutex state that was set" then false is correct, but if the contract is "returns success/failure of the operation" then false here indicates failure, not success. The test conflates the two semantics — a successful unlock (operation succeeded, mutex is now unlocked) should return a clearly-defined value. The same ambiguity applies to returnsTrueWhenLocking.
WHY: Coverage gap — the tests do not verify what happens when the SQL executeUpdate() returns 0 rows affected (no existing row to update). There is no test for the "user does not exist in the mutex table" path for updateUserMutex.
WHERE: src/test/java/com/diamonddagger590/mccore/database/table/impl/MutexDAOTest.javaUpdateUserMutexWithUUID


CONCERN: No tests are present in src/testFixtures/java/ for any of the new functionality. The DAO mocking patterns (connection/statement/resultset setup) are duplicated across MutexDAOTest and TableVersionHistoryDAOTest with no shared fixture.
WHY: Structural problem per checklist — shared fixtures should be in src/testFixtures/java/ so downstream repos (McRPG) can reuse them. Duplicated mock-setup logic that is not in testFixtures cannot be consumed by dependents.
WHERE: src/testFixtures/java/ — absent; MutexDAOTest, TableVersionHistoryDAOTest


Summary

Production files changed: build.gradle.kts (Mockito dependency added); implied production classes BootstrapContext, MutexDAO, TableVersionHistoryDAO, IllegalSlotAssignmentException (and likely BaseGui/Slot — not shown in diff)

Test files present: BootstrapContextTest.java, MutexDAOTest.java, TableVersionHistoryDAOTest.java, IllegalSlotAssignmentExceptionTest.java

Coverage gaps: Migration DDL not verified (only version-tracking write verified); "no update" branches do not assert absence of writes; null/empty inputs untested for DAO public methods; "user does not exist" path for updateUserMutex untested; no tests for BaseGui/PaginatedGui/Slot behavior; IllegalSlotAssignmentException throw-site not tested; no shared testFixtures; all test method names violate givenX_whenY_thenZ convention across all four test files.

@github-actions

Copy link
Copy Markdown

Security Review

No security concerns found.

The diff contains exclusively test infrastructure: Mockito dependency additions in build.gradle.kts and three new test classes (BootstrapContextTest, MutexDAOTest, TableVersionHistoryDAOTest, IllegalSlotAssignmentExceptionTest). No production code paths are introduced or modified. Reviewing against each checklist item:

  • SQL Injection / DDL Injection: No DAO or DDL production code changed. The test code exercises existing DAO static methods through mocked Connection/PreparedStatement objects; the anyString() matchers and verify() calls confirm the tests expect setString()/setInt() binding, consistent with safe parameterized query usage in the underlying production code.
  • MiniMessage Injection: No deserialize() call appears anywhere in the diff.
  • ChatResponse Safety: No ChatResponse implementation touched.
  • onClick() Return Value: No Slot.onClick() implementation present.
  • Framework Permission Gating: No framework operations affecting player state are introduced.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@build.gradle.kts`:
- Around line 68-70: Update the pinned Mockito version by changing the
mockitoVersion variable used by testImplementation (symbol: mockitoVersion and
the two testImplementation("org.mockito:mockito-core:$mockitoVersion") /
testImplementation("org.mockito:mockito-junit-jupiter:$mockitoVersion") entries)
to the latest Java‑21 compatible release (e.g., "5.23.0"); additionally, if your
tests use inline mocking, add/replace the dependency with mockito-inline or
configure the Mockito Java agent (mockito-inline or -javaagent setup) so the
inline mock maker continues to work under Java 21.

In
`@src/test/java/com/diamonddagger590/mccore/bootstrap/BootstrapContextTest.java`:
- Around line 25-83: The test method names in BootstrapContextTest
(pluginAccessor, startupProfileAccessor, prodProfileAccessor, equalContexts,
differentProfiles, differentPlugins, hashCodeConsistency,
toStringContainsClassName) do not follow the givenContext_whenAction_thenOutcome
convention; rename each method to match that pattern (for example:
givenPlugin_whenPluginAccessor_thenReturnsPlugin,
givenPluginAndTestProfile_whenStartupProfileAccessor_thenReturnsTest,
givenPluginAndProdProfile_whenStartupProfileAccessor_thenReturnsProd,
givenSamePluginAndProfile_whenEquals_thenAreEqual,
givenDifferentProfiles_whenEquals_thenNotEqual,
givenDifferentPlugins_whenEquals_thenNotEqual,
givenEqualContexts_whenHashCode_thenMatch,
givenContext_whenToString_thenContainsClassName) while leaving the `@DisplayName`
annotations intact and updating any internal references or IDE-generated usages.
- Line 82: Replace the equality assertion that checks a boolean with an explicit
truth assertion: change the usage of assertEquals(true,
str.contains("BootstrapContext")) to use assertTrue on the condition (i.e., call
assertTrue(str.contains("BootstrapContext"))) so the test uses the clearer
assertion method (reference: BootstrapContextTest, the variable str and the
boolean check str.contains("BootstrapContext")).
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 953d6229-eadc-4be0-91f4-6688d83aefe9

📥 Commits

Reviewing files that changed from the base of the PR and between 6a8d9ea and 6739408.

📒 Files selected for processing (5)
  • build.gradle.kts
  • src/test/java/com/diamonddagger590/mccore/bootstrap/BootstrapContextTest.java
  • src/test/java/com/diamonddagger590/mccore/database/table/impl/MutexDAOTest.java
  • src/test/java/com/diamonddagger590/mccore/database/table/impl/TableVersionHistoryDAOTest.java
  • src/test/java/com/diamonddagger590/mccore/exception/gui/IllegalSlotAssignmentExceptionTest.java

Comment thread build.gradle.kts
Comment on lines +68 to +70
val mockitoVersion = "5.14.2"
testImplementation("org.mockito:mockito-core:$mockitoVersion")
testImplementation("org.mockito:mockito-junit-jupiter:$mockitoVersion")

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🌐 Web query:

What is the latest stable version of Mockito compatible with Java 21 as of June 2026?

💡 Result:

As of June 12, 2026, the latest stable version of Mockito is 5.23.0, which was released on March 11, 2026 [1][2][3]. Mockito 5.x is compatible with Java 21 [4][5][6]. However, starting with Java 21, the JDK introduced stricter restrictions on libraries attaching Java agents to their own JVM [4][5][6]. Consequently, users may need to explicitly configure Mockito as a -javaagent in their build configuration (such as Gradle or Maven) to ensure the inline mock maker functions correctly [4][5][6]. Official documentation provides specific examples for configuring this in Gradle and Maven to maintain compatibility with these JDK security restrictions [4][5][6].

Citations:


Update Mockito to the latest stable compatible with Java 21

In build.gradle.kts (lines 68-70), the project pins Mockito to 5.14.2. The latest stable Mockito release as of June 2026 is 5.23.0 (Java 21 compatible). Updating should improve security/bugfix coverage.

val mockitoVersion = "5.14.2"
testImplementation("org.mockito:mockito-core:$mockitoVersion")
testImplementation("org.mockito:mockito-junit-jupiter:$mockitoVersion")

Also, if the test suite uses inline mocking, Java 21 may require mockito-inline/-javaagent configuration to keep the inline mock maker working.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@build.gradle.kts` around lines 68 - 70, Update the pinned Mockito version by
changing the mockitoVersion variable used by testImplementation (symbol:
mockitoVersion and the two
testImplementation("org.mockito:mockito-core:$mockitoVersion") /
testImplementation("org.mockito:mockito-junit-jupiter:$mockitoVersion") entries)
to the latest Java‑21 compatible release (e.g., "5.23.0"); additionally, if your
tests use inline mocking, add/replace the dependency with mockito-inline or
configure the Mockito Java agent (mockito-inline or -javaagent setup) so the
inline mock maker continues to work under Java 21.

Comment on lines +25 to +83
void pluginAccessor() {
var context = new BootstrapContext<>(mockPlugin, StartupProfile.PROD);
assertEquals(mockPlugin, context.plugin());
}

@Test
@DisplayName("Given a plugin and TEST profile, When constructing BootstrapContext, Then startupProfile() returns TEST")
void startupProfileAccessor() {
var context = new BootstrapContext<>(mockPlugin, StartupProfile.TEST);
assertEquals(StartupProfile.TEST, context.startupProfile());
}

@Test
@DisplayName("Given a plugin and PROD profile, When constructing BootstrapContext, Then startupProfile() returns PROD")
void prodProfileAccessor() {
var context = new BootstrapContext<>(mockPlugin, StartupProfile.PROD);
assertEquals(StartupProfile.PROD, context.startupProfile());
}

@Test
@DisplayName("Given two BootstrapContexts with same plugin and profile, When comparing, Then they are equal")
void equalContexts() {
var context1 = new BootstrapContext<>(mockPlugin, StartupProfile.PROD);
var context2 = new BootstrapContext<>(mockPlugin, StartupProfile.PROD);
assertEquals(context1, context2);
}

@Test
@DisplayName("Given two BootstrapContexts with different profiles, When comparing, Then they are not equal")
void differentProfiles() {
var context1 = new BootstrapContext<>(mockPlugin, StartupProfile.PROD);
var context2 = new BootstrapContext<>(mockPlugin, StartupProfile.TEST);
assertNotEquals(context1, context2);
}

@Test
@DisplayName("Given two BootstrapContexts with different plugins, When comparing, Then they are not equal")
void differentPlugins() {
var context1 = new BootstrapContext<>(mockPlugin, StartupProfile.PROD);
var context2 = new BootstrapContext<>(anotherMockPlugin, StartupProfile.PROD);
assertNotEquals(context1, context2);
}

@Test
@DisplayName("Given two equal BootstrapContexts, When computing hashCode, Then they match")
void hashCodeConsistency() {
var context1 = new BootstrapContext<>(mockPlugin, StartupProfile.TEST);
var context2 = new BootstrapContext<>(mockPlugin, StartupProfile.TEST);
assertEquals(context1.hashCode(), context2.hashCode());
}

@Test
@DisplayName("Given a BootstrapContext, When calling toString, Then it contains the class name")
void toStringContainsClassName() {
var context = new BootstrapContext<>(mockPlugin, StartupProfile.PROD);
String str = context.toString();
assertNotNull(str);
assertEquals(true, str.contains("BootstrapContext"));
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick win

Test method naming convention not followed across all test files.

The coding guidelines require test methods to follow the givenContext_whenAction_thenOutcome naming pattern. This convention is violated consistently across all four test files: BootstrapContextTest.java, MutexDAOTest.java, TableVersionHistoryDAOTest.java, and IllegalSlotAssignmentExceptionTest.java. While the @DisplayName annotations correctly follow Given/When/Then structure and provide good readability, the method names themselves should also follow the stated convention for consistency across the codebase.

The shared root cause is a single naming pattern choice applied throughout this PR. Adopting the required convention in all four files will improve discoverability and align with established project standards.

As per coding guidelines: "Follow the givenContext_whenAction_thenOutcome naming convention for test methods (e.g., givenEmptyPage_whenGetSlots_thenReturnsEmpty)."

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/test/java/com/diamonddagger590/mccore/bootstrap/BootstrapContextTest.java`
around lines 25 - 83, The test method names in BootstrapContextTest
(pluginAccessor, startupProfileAccessor, prodProfileAccessor, equalContexts,
differentProfiles, differentPlugins, hashCodeConsistency,
toStringContainsClassName) do not follow the givenContext_whenAction_thenOutcome
convention; rename each method to match that pattern (for example:
givenPlugin_whenPluginAccessor_thenReturnsPlugin,
givenPluginAndTestProfile_whenStartupProfileAccessor_thenReturnsTest,
givenPluginAndProdProfile_whenStartupProfileAccessor_thenReturnsProd,
givenSamePluginAndProfile_whenEquals_thenAreEqual,
givenDifferentProfiles_whenEquals_thenNotEqual,
givenDifferentPlugins_whenEquals_thenNotEqual,
givenEqualContexts_whenHashCode_thenMatch,
givenContext_whenToString_thenContainsClassName) while leaving the `@DisplayName`
annotations intact and updating any internal references or IDE-generated usages.

Source: Coding guidelines

var context = new BootstrapContext<>(mockPlugin, StartupProfile.PROD);
String str = context.toString();
assertNotNull(str);
assertEquals(true, str.contains("BootstrapContext"));

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Use assertTrue instead of assertEquals(true, ...).

Replace assertEquals(true, str.contains("BootstrapContext")) with assertTrue(str.contains("BootstrapContext")) for clearer intent and better failure messages.

✨ Proposed fix
-        assertEquals(true, str.contains("BootstrapContext"));
+        assertTrue(str.contains("BootstrapContext"));
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@src/test/java/com/diamonddagger590/mccore/bootstrap/BootstrapContextTest.java`
at line 82, Replace the equality assertion that checks a boolean with an
explicit truth assertion: change the usage of assertEquals(true,
str.contains("BootstrapContext")) to use assertTrue on the condition (i.e., call
assertTrue(str.contains("BootstrapContext"))) so the test uses the clearer
assertion method (reference: BootstrapContextTest, the variable str and the
boolean check str.contains("BootstrapContext")).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants