Clean-account testen mist het belangrijke defect
Een nieuwe Unity build kan er perfect uitzien wanneer het begint met een leeg profiel. Een nieuwe account heeft geen gepensioneerde velden, halve quests, gecached catalogus referenties, oude inventaris stacks, onderbroken aankopen, of waarden die geldig waren onder een eerdere regelset. Het bewijst daarom alleen dat het nieuwe formaat een nieuwe staat kan creëren. Het zegt heel weinig over de vraag of het spel kan veilig dragen een speler van gisteren een wereld in vandaag.
Migratie werk moet beginnen met een sterkere vraag: kan deze exacte historische staat de huidige bouw binnengaan, de betekenis behouden die er nog steeds toe doet, en ofwel geldig worden huidige staat of falen op een manier die nuttig is om te diagnosticeren? Dat is een product vraag zoveel als een serializer vraag. Een veld kan deserialiseren succesvol terwijl nog steeds het overtreden van een progressieregel, wijzen op ontbrekende inhoud, of het veranderen van een aankooprecht.
Dit artikel beschrijft een lokaal-eerste repetitieproces. Het is bewust geen belofte dat één tool elke Unity serialization setup, backend of platformintegratie kan begrijpen. Unity datamodellen variëren, en een spel kan zijn eigen encryptie, cloud-synchronisatie, binair formaat of aangepaste adapters toevoegen. Het duurzame deel is de test discipline: behoud historische vormen, kopieer ze voor mutatie, maak het migratiepad expliciet, en controleer game-invarianten na elke grens.
Bouw een historisch staatscorpus
Behandel oude opgeslagen als een versioned corpus, niet als losse bestanden die in chat worden doorgegeven. Elke armatuur heeft een stabiele identificatie nodig, de versie die het heeft geproduceerd, een kort scenariolabel, een formatverklaring en een privacy classificatie. Het scenariolabel is belangrijk omdat een migratiesuite betekenisvolle toestanden moet bevatten, niet alleen willekeurige JSON. Voorbeelden zijn een nieuwe speler, een speler aan een hoofdstukgrens, een inventaris op zijn stacklimiet, een onderbroken tutorial, een oude gebeurtenisbeloning, een gebruiker met optionele cosmetische inhoud, en een profiel dat opzettelijk een ongeldige legacy combinatie bevat.
Gebruik onveranderlijke werkkopieën. De testrunner moet de bronarmatuur nooit overschrijven tijdens het proberen van een migratie. Kopieer de armatuur naar een tijdelijke werkmap, registreer de controlesom of de inhoudhash, voer de adapter uit en behoud de resulterende uitvoer apart. Dit verandert een verrassend resultaat in bewijs dat iemand anders kan herhalen. Het voorkomt ook dat een test stil zijn eigen invoer verbetert totdat het oorspronkelijke probleem verdwijnt.
Houd productie speler gegevens uit een algemene ontwikkeling armatuur directory. Een historisch corpus kan worden synthetisch, goedgekeurd, zorgvuldig geredigeerd, of gegenereerd uit deterministische scenario's. De sleutel is dat het behoudt de structurele en semantische rand gevallen die ertoe doen. Privacy is geen nagedachte: verwijder directe identificaties, apparaat identificaties, contact informatie, betaling tokens, ruwe ontvangstbewijzen, en geheimen voordat een armatuur wordt breed toegankelijk.
Teken de migratiegrafiek voordat u een converter schrijft
Versienummers zijn geen migratieplan. Een spel kan bewegen van 1 naar 2, 2 naar 3, en 3 naar 4, dan een speler tegenkomen die rechtstreeks van 1 naar 4 is overgeslagen. Het kan een hotfix verzenden dat alleen een nested inventarisrecord verandert, of een veld met pensioen laten gaan dat oude inhoud nog steeds verwacht. Een grafiek maakt deze keuzes zichtbaar: elke node is een save schema of semantische versie; elke rand is een expliciete transformatie of een opzettelijke afwijzing; elke rand heeft voorwaarden en postvoorwaarden.
Voor elke ondersteunde startversie, beslissen of de spelketens naast elkaar transformeert, een directe transformatie gebruikt of een service-side upgrade vereist voordat de client laadt. Laat geen overgeslagen versies over aan wat er gebeurt wanneer velden ontbreken. Een keten kan veiliger zijn wanneer elke stap klein is en getest. Een directe transformatie kan veiliger zijn wanneer intermediaire formaten nooit bedoeld zijn om waarneembaar te zijn. Beide benaderingen hebben een duidelijke eigendom en herhaalbare armaturen nodig.
De grafiek moet meer bevatten dan het seriële type. Record inhoud catalogus afhankelijkheden, configuratieversies, feature flags die van invloed zijn op de interpretatie, en de huidige toepassing versie. Een opslaan kan syntactisch huidig zijn maar ongeldig omdat een referentie item niet meer bestaat of een regel veranderde betekenis. Dat zijn compatibiliteit grenzen, niet vervelend rand gevallen.
Maak het opslaan-load ronde reizen waarneembaar
Zodra een armatuur het migratiepad ingaat, voert u een volledige ronde reis uit: laad de historische input, migreren, construeren het in-game model, opslaan met behulp van de huidige schrijver, dan laadt u die huidige uitvoer opnieuw. De eerste lading controleert of een historische record het systeem kan invoeren. De tweede lading controleert of de huidige schrijver een stabiel, zelfconsistent resultaat heeft gecreëerd. Vergelijk de toestand na de eerste en tweede belasting volgens semantische regels, niet alleen rauwe byte gelijkheid.
Rauwe gelijkheid is vaak de verkeerde bewering. Nieuwe defaults kunnen worden toegevoegd, veld orde kan veranderen, tijdstempels kunnen worden ververst, en collecties kunnen stabiele bestelling ontvangen. Definieer een normalizer voor waarden die opzettelijk niet-semantisch zijn, dan de rest te vergelijken. De normalizer zelf verdient herziening; het mag geen deken negeren lijst die echt verlies verbergt. Een goede vergelijking rapporten die velden werden toegevoegd, verwijderd, getransformeerd of opzettelijk genegeerd.
Het testresultaat moet de eerste ongeldige staat noemen. Als een migratieketen drie overgangen heeft, niet alleen melden dat de uiteindelijke belasting mislukt. Neem de staat na elk controlepunt, valideren, en stop bij de vroegste grens die een invariant schendt. Dat lokalisatie zet een vage .oude opslaan gebroken . rapport in een specifieke migratie edge, armatuur, en staat verschil.
Express game-specifieke varianten
Een algemeen migratie harnas kan niet weten wat progressie betekent in een bepaald spel. Het spel moet zijn eigen invarianten bieden. Schrijf ze in taal die verbinding maakt met de resultaten van de speler: een niveau is binnen het huidige bereik; een inventaris hoeveelheid is niet-negatief en begrensd; elk eigendom item heeft een bekende definitie of een expliciete nalatenschap terugval; een voltooide tutorial blijft voltooid; valuta is eindig; een zoektocht referentie behoort tot een huidige catalogus; een recht is uniek; een wereldzaad en gegenereerde wereldstaat akkoord.
Scheid invarianten in lagen. Structurele invarianten antwoorden of er verplichte velden en typen bestaan. Referential invarianten antwoorden of ID's wijzen op bekende definities. Domeinininvarianten antwoorden of waarden zich aan de spelregels houden. Veiligheidsinvarianten antwoorden of gegevens eindig, begrensd en veilig zijn om weer te geven. Wanneer een armatuur uitvalt, vertelt de laag het team of het een serializer-wijziging, catalogusadapter, regelset-beslissing of herstelbeleid nodig heeft.
Gebruik deterministische mutaties om het corpus harder te laten werken. Begin met een bekende armatuur en verwijder bewust een veld, dupliceer een inventaris-ID, vervang een catalogusreferentie, sla een versie over, herschikk een actielijst, of wijzig een grenshoeveelheid. Elke mutatie moet een verwacht resultaat hebben: migreren met een gedocumenteerde standaard, weigeren met een diagnostische categorie, quarantaine voor herstel, of een door de eigenaar goedgekeurde gegevensreparatie vereisen.
Een mislukte opslaan verminderen zonder de bug te verliezen
Grote speler staten zijn moeilijk te begrijpen. Als een armatuur bevat honderden velden en een migratie mislukt, kan een ontwikkelaar uren doorbrengen met het lezen van niet-gerelateerde gegevens. Tegenvoorbeeld minimalisering vermindert de armatuur terwijl het behoud van de geschonden invariant. Verwijder een veldgroep, probeer dezelfde deterministische migratie, en houd de verwijdering alleen wanneer de storing nog steeds optreedt. Dan partitie collecties, krimp waarden in de richting van grenzen, en verminderen de actie geschiedenis als replay gedrag zaken.
Reductie vereist reproduceerbaarheid. Vergrendel de armatuur hash, migratie versie, adapter versie, deterministisch seed, relevante configuratie snapshot, en verwachte invariant. Als de omgeving verandert tijdens elke retry, een reducer kan een kleinere toestand voor een ander probleem produceren. Houd een replay manifest met die inputs en het waargenomen resultaat. De output is niet alleen een kleiner bestand; het is een regressie geval dat iemand anders kan uitvoeren.
Gegenereerde regressie-armaturen moeten hetzelfde beoordelingspad invoeren als met de hand geschreven. Geef elke armatuur een stabiele naam, een korte uitleg van het falen, de invariant die het bewaart, en een verwachte classificatie. Een regressie-armatuur is waardevol omdat het een eerder verrassende grens routine maakt. Het mag geen verborgen bron van productie-spelergegevens of een catch-all voor onverklaarbare storingen worden.
Zet de repetitie in CI zonder het luidruchtig te maken
Voer een snelle representatieve subset op elke relevante verandering: huidige migratie randen, hoog risico historische toestanden, en een kleine set van deterministische mutaties. Voer het volledige corpus op een geplande taak, release candidate, of verandering die raakt serialisatie, progressie, catalogus interpretatie, cloud-synchronisatie, of save-format code. Gedeeld door armage familie of migratie rand in plaats van het verzenden van elke test door middel van een lange reeks.
CI-uitvoer moet beknopt zijn, maar geïnspecteerd. Rapporteer de armatuur-ID, begin- en doelversies, migratierand, invariante laag, eerste ongeldige controlepunt en een pad naar het geredacteerde artefact of diff. Vermijd het afdrukken van volledige profielinhoud in logs. Wanneer een fout nieuw is, bewaar de minimale informatie die nodig is om het lokaal te reproduceren; wanneer het wordt verwacht, noteer dat classificatie, zodat een release niet stil normaliseren een bekend risico.
De beslissing over de vrijgave moet aangeven wat het bewijs betekent. Het passeren van migratietests ondersteunen een begrensde claim: het geteste corpus en de aangegeven paden gedragen zich zoals verwacht in die omgeving. Ze bewijzen niet elke speler opslaan, apparaat, of externe service zal zich identiek gedragen. Teams nog steeds nodig rollback plannen, klant-ondersteuning behandeling, en het toezicht op dat respect privacy.
Praktische controlelijst
- Houd een versioned historisch corpus met scenariolabels en privacy classificaties.
- Kopieer invoer voor migratie en bewaar hashes voor bron- en uitvoer artefacten.
- Teken ondersteunde migratieranden, inclusief overgeslagen versiebeleid en expliciete afwijzingen.
- Valideer structurele, referentie-, domein- en veiligheidsinvarianten na elk controlepunt.
- Rondreis gemigreerde uitvoer via de huidige schrijver en lezer.
- Gebruik deterministische mutaties om ontbrekende velden, dubbele records, gepensioneerde inhoud en grenswaarden te testen.
- Reduceer reproduceerbaare storingen in beoordeelde regressiearmaturen met herhalingsmanifesten.
- Voer risicogeoriënteerde subgroepen continu uit en het volledige corpus voordat u gevoelige veranderingen loslaat.
- Houd logs en artefacten geredigeerd; verander CI niet in een archief met spelergegevens.
Veelgestelde vragen
Hebben we echte spelers nodig om migratie te testen?
Nee. Echte historische vormen zijn nuttig, maar het corpus kan synthetisch of zorgvuldig worden geredigeerd. Waar het om gaat is het behouden van de moeilijke staat combinaties: gepensioneerde inhoud, lange progressie, onderbroken overgangen, optionele gegevens, en waarden aan betekenisvolle grenzen. Als productiegegevens worden gebruikt om een rand geval te ontdekken, leiden een veilige armatuur die alleen de eigenschap te behouden te testen.
Moet elke oude versie altijd ondersteund blijven?
Niet noodzakelijk. Ondersteuning is een product en operationele beslissing. Het belangrijkste is om de grens expliciet te maken: welke versies migreren, die een eerdere update vereisen, die worden afgewezen, en hoe de speler wordt geïnformeerd. Een ongedocumenteerd toevallig pad is de minst veilige optie omdat het niet betrouwbaar wordt ondersteund of duidelijk geweigerd.
Kan een serializer test gameplay testen vervangen?
Nee. Serializer tests stellen vast dat gegevens kunnen worden gelezen en geschreven volgens de aangegeven vormen. Gameplay en domeintesten stellen vast dat de resulterende toestand zinvol is in de huidige regelset. Een robuuste migratie repetitie zowel nodig, plus een beoordeling van de inhoud en configuratie referenties die de betekenis van opgeslagen waarden beïnvloeden.
Wat is de rol van Persistium?
Persistium is een in-development lokaal-eerste betrouwbaarheid product familie. De leidraad in deze notitie is praktisch engineering advies, niet een claim dat een publieke Persistium product beschikbaar is of dat het heeft gediagnosticeerd echte klantgegevens. De Continuity Direction onderzoekt het soort expliciete migratie, herhaling, vergelijking en reductie workflow hierboven beschreven.
