Class SaveLoadTests
- Namespace
- GrindFest
- Assembly
- GrindFest.dll
Save & load at the level SkillSaveRoundTripTests does not reach: the file, the path it
goes to, and whether a written save is the one Load() will look for.
Why the path assertion is the important one here: SaveManager.saveFile was a serialized field filled
only by OnValidate, which runs in the editor alone, so every build carried the build machine's
absolute path (measured 2026-09-20: …/C:/Users/<name>/AppData/…/Saves/savedata.json). On WebGL that is
outside Application.persistentDataPath — the only tree Unity syncs to IndexedDB — so the save silently
did not survive a reload while the console still said "Game saved to …". A path assertion catches that in any
build, including one nobody is debugging.
The write test restores the original save bytes afterwards. DevTests are destructive by design, but a save test that eats the player's party would be destructive in the worst possible place.
public class SaveLoadTests : DevTest
- Inheritance
-
objectSaveLoadTests
- Inherited Members
Methods
- HeroLevelStatsAndClassSurviveARoundTrip()
The state a player would notice losing, through the real save/load pair rather than a copy of it. Nothing is written to the live hero: a throwaway HeroData is doctored and loaded, so the assertion cannot be satisfied by accident and the party is left exactly as it was found.
- SavePathLivesUnderPersistentDataPath()
The one that would have caught the bug: wherever a build thinks it saves, that has to be a path the platform keeps between runs.
- SaveWritesTheFileLoadReads()
A save that is written has to be a file at saveFile with content in it, because that is exactly where
Load()reads. The original bytes are put back before the test ends.