The Persistence surface lets you verify that world save paths are configured and that the player storage system is accessible.Documentation Index
Fetch the complete documentation index at: https://docs.hrtk.frotty27.com/llms.txt
Use this file to discover all available pages before exploring further.
PersistenceTestAdapter provides direct lookups, while PersistenceAssert wraps them as failing assertions with clear messages.
Persistence testing matters because silent save failures are the worst kind of bug - players lose progress with no error message. These tests verify that the save infrastructure is wired up correctly before your mod tries to persist data.
Complete Example Suite
Adapter Methods
| Method | Returns | Description |
|---|---|---|
getWorldSavePath(Object world) | Path | Get the save path for a world (returns null if unavailable) |
getPlayerStorage() | Object | Get the player storage instance from the Universe |
playerStorageAvailable() | boolean | Check if the PlayerStorage class is on the classpath |
Assertion Methods
| Method | Failure Message |
|---|---|
assertWorldSavePathExists(Object world) | ”Expected world save path to be non-null but it was null” |
assertPlayerStorageAvailable() | ”Expected player storage to be available but it was not” |
When to Test Persistence
Persistence tests are valuable as:- Smoke tests - Run on every build to verify the save infrastructure is wired up
- Precondition guards - Check save path existence before running tests that persist data
- Build validation - Catch server configurations where persistence is accidentally disabled
playerStorageAvailable() from the adapter as a precondition guard before running tests that depend on player data persistence.
Next Steps
- Plugins - verify plugin loading state
- World Testing - world operations that may persist
- Scheduling - world liveness checks