Spike: plugwright in-game E2E tests (validates #329 on 1.8.0)

[tastybento]

A working spike of plugwright for in-game / end-to-end testing — the layer our 517 MockBukkit unit tests can't reach. It boots a real Paper 1.21.11 server with BentoBox 3.14.0 + BSkyBlock 1.20.0 + the built Challenges jar, and drives a headless Mineflayer bot that runs commands and clicks GUIs.

It works — and it validated a 1.8.0 feature in-game

Two green tests (e2e/src/test/e2e/challenges.spec.ts):

• smoke — bot joins 1.21.11, ops, runs a command, receives the reply (proves the whole stack loads and is drivable).
• Suggestion: Improve challenges confirmation (Please confirm that you want to replace your current challenges with new one.) #329 — bot opens the Challenges admin GUI, clicks Challenge Wipe, and receives the confirmation instruction line added in Improve #329: tell players how to answer confirmation prompts #415:

  Please confirm that you want to clear the challenges database for BSkyBlock.
Type 'confirm' in chat to proceed, or 'cancel' to abort.

That's a real end-to-end validation of the staged 1.8.0 release, in-game, on the exact target MC version.

How it's wired

• A separate Gradle sidecar under e2e/ — does not touch the Maven build. Deploys prebuilt jars (useExternalPluginsOnly + writeFiles); BentoBox + BSkyBlock are downloaded (cached in .deps/), Challenges comes from ../target/.
• Key gotcha (documented in e2e/README.md + build.gradle.kts): BentoBox addons must be staged into plugins/BentoBox/addons/, not plugins/ — otherwise they load as bare Paper plugins, no bskyblock_world is created, and every gamemode command returns "Unknown". This is the BentoBox bootstrap subtlety the spike was meant to surface.
• CI: .github/workflows/e2e.yml runs on demand (workflow_dispatch) — advisory/opt-in, deliberately not on every PR yet (a run boots a server + generates worlds, ~1–2 min).

Findings / limits

• 1.21.11 bot support, multi-plugin load, GUI clicks, Maven integration: all fine. Runs are ~30–40s locally.
• Tests needing an island (block/biome/completion flows) still need island bootstrap (bot-driven /island create, or a pre-staged world via writeFiles) — a sensible next step if we want deeper coverage.

Opening as a spike for review — happy to expand coverage or drop it if the maintenance/runtime cost isn't worth it.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tastybento]

A working spike of plugwright for in-game / end-to-end testing — the layer our 517 MockBukkit unit tests can't reach. It boots a real Paper 1.21.11 server with BentoBox 3.14.0 + BSkyBlock 1.20.0 + the built Challenges jar, and drives a headless Mineflayer bot that runs commands and clicks GUIs.

It works — and it validated a 1.8.0 feature in-game

Two green tests (e2e/src/test/e2e/challenges.spec.ts):

• smoke — bot joins 1.21.11, ops, runs a command, receives the reply (proves the whole stack loads and is drivable).
• Suggestion: Improve challenges confirmation (Please confirm that you want to replace your current challenges with new one.) #329 — bot opens the Challenges admin GUI, clicks Challenge Wipe, and receives the confirmation instruction line added in Improve #329: tell players how to answer confirmation prompts #415:

  Please confirm that you want to clear the challenges database for BSkyBlock.
Type 'confirm' in chat to proceed, or 'cancel' to abort.

That's a real end-to-end validation of the staged 1.8.0 release, in-game, on the exact target MC version.

How it's wired

• A separate Gradle sidecar under e2e/ — does not touch the Maven build. Deploys prebuilt jars (useExternalPluginsOnly + writeFiles); BentoBox + BSkyBlock are downloaded (cached in .deps/), Challenges comes from ../target/.
• Key gotcha (documented in e2e/README.md + build.gradle.kts): BentoBox addons must be staged into plugins/BentoBox/addons/, not plugins/ — otherwise they load as bare Paper plugins, no bskyblock_world is created, and every gamemode command returns "Unknown". This is the BentoBox bootstrap subtlety the spike was meant to surface.
• CI: .github/workflows/e2e.yml runs on demand (workflow_dispatch) — advisory/opt-in, deliberately not on every PR yet (a run boots a server + generates worlds, ~1–2 min).

Findings / limits

• 1.21.11 bot support, multi-plugin load, GUI clicks, Maven integration: all fine. Runs are ~30–40s locally.
• Tests needing an island (block/biome/completion flows) still need island bootstrap (bot-driven /island create, or a pre-staged world via writeFiles) — a sensible next step if we want deeper coverage.

Opening as a spike for review — happy to expand coverage or drop it if the maintenance/runtime cost isn't worth it.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tastybento]

A working spike of plugwright for in-game / end-to-end testing — the layer our 517 MockBukkit unit tests can't reach. It boots a real Paper 1.21.11 server with BentoBox 3.14.0 + BSkyBlock 1.20.0 + the built Challenges jar, and drives a headless Mineflayer bot that runs commands and clicks GUIs.

It works — and it validated a 1.8.0 feature in-game

Two green tests (e2e/src/test/e2e/challenges.spec.ts):

• smoke — bot joins 1.21.11, ops, runs a command, receives the reply (proves the whole stack loads and is drivable).
• Suggestion: Improve challenges confirmation (Please confirm that you want to replace your current challenges with new one.) #329 — bot opens the Challenges admin GUI, clicks Challenge Wipe, and receives the confirmation instruction line added in Improve #329: tell players how to answer confirmation prompts #415:

  Please confirm that you want to clear the challenges database for BSkyBlock.
Type 'confirm' in chat to proceed, or 'cancel' to abort.

That's a real end-to-end validation of the staged 1.8.0 release, in-game, on the exact target MC version.

How it's wired

• A separate Gradle sidecar under e2e/ — does not touch the Maven build. Deploys prebuilt jars (useExternalPluginsOnly + writeFiles); BentoBox + BSkyBlock are downloaded (cached in .deps/), Challenges comes from ../target/.
• Key gotcha (documented in e2e/README.md + build.gradle.kts): BentoBox addons must be staged into plugins/BentoBox/addons/, not plugins/ — otherwise they load as bare Paper plugins, no bskyblock_world is created, and every gamemode command returns "Unknown". This is the BentoBox bootstrap subtlety the spike was meant to surface.
• CI: .github/workflows/e2e.yml runs on demand (workflow_dispatch) — advisory/opt-in, deliberately not on every PR yet (a run boots a server + generates worlds, ~1–2 min).

Findings / limits

• 1.21.11 bot support, multi-plugin load, GUI clicks, Maven integration: all fine. Runs are ~30–40s locally.
• Tests needing an island (block/biome/completion flows) still need island bootstrap (bot-driven /island create, or a pre-staged world via writeFiles) — a sensible next step if we want deeper coverage.

Opening as a spike for review — happy to expand coverage or drop it if the maintenance/runtime cost isn't worth it.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tastybento]

A working spike of plugwright for in-game / end-to-end testing — the layer our 517 MockBukkit unit tests can't reach. It boots a real Paper 1.21.11 server with BentoBox 3.14.0 + BSkyBlock 1.20.0 + the built Challenges jar, and drives a headless Mineflayer bot that runs commands and clicks GUIs.

It works — and it validated a 1.8.0 feature in-game

Two green tests (e2e/src/test/e2e/challenges.spec.ts):

• smoke — bot joins 1.21.11, ops, runs a command, receives the reply (proves the whole stack loads and is drivable).
• Suggestion: Improve challenges confirmation (Please confirm that you want to replace your current challenges with new one.) #329 — bot opens the Challenges admin GUI, clicks Challenge Wipe, and receives the confirmation instruction line added in Improve #329: tell players how to answer confirmation prompts #415:

  Please confirm that you want to clear the challenges database for BSkyBlock.
Type 'confirm' in chat to proceed, or 'cancel' to abort.

That's a real end-to-end validation of the staged 1.8.0 release, in-game, on the exact target MC version.

How it's wired

• A separate Gradle sidecar under e2e/ — does not touch the Maven build. Deploys prebuilt jars (useExternalPluginsOnly + writeFiles); BentoBox + BSkyBlock are downloaded (cached in .deps/), Challenges comes from ../target/.
• Key gotcha (documented in e2e/README.md + build.gradle.kts): BentoBox addons must be staged into plugins/BentoBox/addons/, not plugins/ — otherwise they load as bare Paper plugins, no bskyblock_world is created, and every gamemode command returns "Unknown". This is the BentoBox bootstrap subtlety the spike was meant to surface.
• CI: .github/workflows/e2e.yml runs on demand (workflow_dispatch) — advisory/opt-in, deliberately not on every PR yet (a run boots a server + generates worlds, ~1–2 min).

Findings / limits

• 1.21.11 bot support, multi-plugin load, GUI clicks, Maven integration: all fine. Runs are ~30–40s locally.
• Tests needing an island (block/biome/completion flows) still need island bootstrap (bot-driven /island create, or a pre-staged world via writeFiles) — a sensible next step if we want deeper coverage.

Opening as a spike for review — happy to expand coverage or drop it if the maintenance/runtime cost isn't worth it.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tastybento]

A working spike of plugwright for in-game / end-to-end testing — the layer our 517 MockBukkit unit tests can't reach. It boots a real Paper 1.21.11 server with BentoBox 3.14.0 + BSkyBlock 1.20.0 + the built Challenges jar, and drives a headless Mineflayer bot that runs commands and clicks GUIs.

It works — and it validated a 1.8.0 feature in-game

Two green tests (e2e/src/test/e2e/challenges.spec.ts):

• smoke — bot joins 1.21.11, ops, runs a command, receives the reply (proves the whole stack loads and is drivable).
• Suggestion: Improve challenges confirmation (Please confirm that you want to replace your current challenges with new one.) #329 — bot opens the Challenges admin GUI, clicks Challenge Wipe, and receives the confirmation instruction line added in Improve #329: tell players how to answer confirmation prompts #415:

  Please confirm that you want to clear the challenges database for BSkyBlock.
Type 'confirm' in chat to proceed, or 'cancel' to abort.

That's a real end-to-end validation of the staged 1.8.0 release, in-game, on the exact target MC version.

How it's wired

• A separate Gradle sidecar under e2e/ — does not touch the Maven build. Deploys prebuilt jars (useExternalPluginsOnly + writeFiles); BentoBox + BSkyBlock are downloaded (cached in .deps/), Challenges comes from ../target/.
• Key gotcha (documented in e2e/README.md + build.gradle.kts): BentoBox addons must be staged into plugins/BentoBox/addons/, not plugins/ — otherwise they load as bare Paper plugins, no bskyblock_world is created, and every gamemode command returns "Unknown". This is the BentoBox bootstrap subtlety the spike was meant to surface.
• CI: .github/workflows/e2e.yml runs on demand (workflow_dispatch) — advisory/opt-in, deliberately not on every PR yet (a run boots a server + generates worlds, ~1–2 min).

Findings / limits

• 1.21.11 bot support, multi-plugin load, GUI clicks, Maven integration: all fine. Runs are ~30–40s locally.
• Tests needing an island (block/biome/completion flows) still need island bootstrap (bot-driven /island create, or a pre-staged world via writeFiles) — a sensible next step if we want deeper coverage.

Opening as a spike for review — happy to expand coverage or drop it if the maintenance/runtime cost isn't worth it.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tastybento]

A working spike of plugwright for in-game / end-to-end testing — the layer our 517 MockBukkit unit tests can't reach. It boots a real Paper 1.21.11 server with BentoBox 3.14.0 + BSkyBlock 1.20.0 + the built Challenges jar, and drives a headless Mineflayer bot that runs commands and clicks GUIs.

It works — and it validated a 1.8.0 feature in-game

Two green tests (e2e/src/test/e2e/challenges.spec.ts):

• smoke — bot joins 1.21.11, ops, runs a command, receives the reply (proves the whole stack loads and is drivable).
• Suggestion: Improve challenges confirmation (Please confirm that you want to replace your current challenges with new one.) #329 — bot opens the Challenges admin GUI, clicks Challenge Wipe, and receives the confirmation instruction line added in Improve #329: tell players how to answer confirmation prompts #415:

  Please confirm that you want to clear the challenges database for BSkyBlock.
Type 'confirm' in chat to proceed, or 'cancel' to abort.

That's a real end-to-end validation of the staged 1.8.0 release, in-game, on the exact target MC version.

How it's wired

• A separate Gradle sidecar under e2e/ — does not touch the Maven build. Deploys prebuilt jars (useExternalPluginsOnly + writeFiles); BentoBox + BSkyBlock are downloaded (cached in .deps/), Challenges comes from ../target/.
• Key gotcha (documented in e2e/README.md + build.gradle.kts): BentoBox addons must be staged into plugins/BentoBox/addons/, not plugins/ — otherwise they load as bare Paper plugins, no bskyblock_world is created, and every gamemode command returns "Unknown". This is the BentoBox bootstrap subtlety the spike was meant to surface.
• CI: .github/workflows/e2e.yml runs on demand (workflow_dispatch) — advisory/opt-in, deliberately not on every PR yet (a run boots a server + generates worlds, ~1–2 min).

Findings / limits

• 1.21.11 bot support, multi-plugin load, GUI clicks, Maven integration: all fine. Runs are ~30–40s locally.
• Tests needing an island (block/biome/completion flows) still need island bootstrap (bot-driven /island create, or a pre-staged world via writeFiles) — a sensible next step if we want deeper coverage.

Opening as a spike for review — happy to expand coverage or drop it if the maintenance/runtime cost isn't worth it.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tastybento]

A working spike of plugwright for in-game / end-to-end testing — the layer our 517 MockBukkit unit tests can't reach. It boots a real Paper 1.21.11 server with BentoBox 3.14.0 + BSkyBlock 1.20.0 + the built Challenges jar, and drives a headless Mineflayer bot that runs commands and clicks GUIs.

It works — and it validated a 1.8.0 feature in-game

Two green tests (e2e/src/test/e2e/challenges.spec.ts):

• smoke — bot joins 1.21.11, ops, runs a command, receives the reply (proves the whole stack loads and is drivable).
• Suggestion: Improve challenges confirmation (Please confirm that you want to replace your current challenges with new one.) #329 — bot opens the Challenges admin GUI, clicks Challenge Wipe, and receives the confirmation instruction line added in Improve #329: tell players how to answer confirmation prompts #415:

  Please confirm that you want to clear the challenges database for BSkyBlock.
Type 'confirm' in chat to proceed, or 'cancel' to abort.

That's a real end-to-end validation of the staged 1.8.0 release, in-game, on the exact target MC version.

How it's wired

• A separate Gradle sidecar under e2e/ — does not touch the Maven build. Deploys prebuilt jars (useExternalPluginsOnly + writeFiles); BentoBox + BSkyBlock are downloaded (cached in .deps/), Challenges comes from ../target/.
• Key gotcha (documented in e2e/README.md + build.gradle.kts): BentoBox addons must be staged into plugins/BentoBox/addons/, not plugins/ — otherwise they load as bare Paper plugins, no bskyblock_world is created, and every gamemode command returns "Unknown". This is the BentoBox bootstrap subtlety the spike was meant to surface.
• CI: .github/workflows/e2e.yml runs on demand (workflow_dispatch) — advisory/opt-in, deliberately not on every PR yet (a run boots a server + generates worlds, ~1–2 min).

Findings / limits

• 1.21.11 bot support, multi-plugin load, GUI clicks, Maven integration: all fine. Runs are ~30–40s locally.
• Tests needing an island (block/biome/completion flows) still need island bootstrap (bot-driven /island create, or a pre-staged world via writeFiles) — a sensible next step if we want deeper coverage.

Opening as a spike for review — happy to expand coverage or drop it if the maintenance/runtime cost isn't worth it.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tastybento]

A working spike of plugwright for in-game / end-to-end testing — the layer our 517 MockBukkit unit tests can't reach. It boots a real Paper 1.21.11 server with BentoBox 3.14.0 + BSkyBlock 1.20.0 + the built Challenges jar, and drives a headless Mineflayer bot that runs commands and clicks GUIs.

It works — and it validated a 1.8.0 feature in-game

Two green tests (e2e/src/test/e2e/challenges.spec.ts):

• smoke — bot joins 1.21.11, ops, runs a command, receives the reply (proves the whole stack loads and is drivable).
• Suggestion: Improve challenges confirmation (Please confirm that you want to replace your current challenges with new one.) #329 — bot opens the Challenges admin GUI, clicks Challenge Wipe, and receives the confirmation instruction line added in Improve #329: tell players how to answer confirmation prompts #415:

  Please confirm that you want to clear the challenges database for BSkyBlock.
Type 'confirm' in chat to proceed, or 'cancel' to abort.

That's a real end-to-end validation of the staged 1.8.0 release, in-game, on the exact target MC version.

How it's wired

• A separate Gradle sidecar under e2e/ — does not touch the Maven build. Deploys prebuilt jars (useExternalPluginsOnly + writeFiles); BentoBox + BSkyBlock are downloaded (cached in .deps/), Challenges comes from ../target/.
• Key gotcha (documented in e2e/README.md + build.gradle.kts): BentoBox addons must be staged into plugins/BentoBox/addons/, not plugins/ — otherwise they load as bare Paper plugins, no bskyblock_world is created, and every gamemode command returns "Unknown". This is the BentoBox bootstrap subtlety the spike was meant to surface.
• CI: .github/workflows/e2e.yml runs on demand (workflow_dispatch) — advisory/opt-in, deliberately not on every PR yet (a run boots a server + generates worlds, ~1–2 min).

Findings / limits

• 1.21.11 bot support, multi-plugin load, GUI clicks, Maven integration: all fine. Runs are ~30–40s locally.
• Tests needing an island (block/biome/completion flows) still need island bootstrap (bot-driven /island create, or a pre-staged world via writeFiles) — a sensible next step if we want deeper coverage.

Opening as a spike for review — happy to expand coverage or drop it if the maintenance/runtime cost isn't worth it.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud