Clean-konto testing savner den viktige feilen
En ny Unity-bygning kan se perfekt ut når den starter med en tom profil. En ny konto har ingen pensjonerte felt, halvferdige søk, cached katalog referanser, gamle lagerhauger, avbrutte kjøp eller verdier som var gyldige under et tidligere regelsett. Det beviser derfor bare at det nye formatet kan skape en ny tilstand. Det sier svært lite om om spillet trygt kan bære en spiller fra gårsdagens verden til dagens en.
Migrasjonsarbeid bør begynne fra et sterkere spørsmål: kan denne nøyaktige historiske tilstanden komme inn i den nåværende bygg, bevare betydningen som fortsatt betyr noe, og enten bli gyldig aktuell tilstand eller mislykkes på en måte som er nyttig for å diagnostisere? Det er et produktspørsmål så mye som en serialiseringsspørsmål. Et felt kan deserialisere vellykket mens du fortsatt bryter en progresjonsregel, peker på manglende innhold eller endrer en kjøpsrett. Laster bytene er ikke nok.
Denne artikkelen beskriver en lokal-første øvingsprosessen. Det er bevisst ikke et løfte om at ett verktøy kan forstå hver Unity seriealiseringsoppsett, backend eller plattform integrasjon. Unity datamodeller varierer, og et spill kan legge til sin egen kryptering, skysynkronisering, binærformat eller egendefinerte adaptere. Den holdbare delen er test disiplin: bevare historiske former, kopiere dem før mutasjon, gjøre migrasjonsvei eksplisitt, og sjekke spillet invarianter etter hver grense.
Bygg en historisk stat corpus
Behandling gamle lagres som en versjon corpus, ikke som løse filer passert i chat. Hver fixture trenger en stabil identifikator, versjonen som produserte det, en kort scenario etikett, en formaterklæring og en personvernklassifisering. Sceneetiketten gjelder fordi en migrasjonssuite bør inneholde meningsfulle tilstander, ikke bare tilfeldig JSON. Eksempler inkluderer en ny spiller, en spiller ved en kapittelgrense, en inventar ved sin stabelgrense, en avbrutt tutorial, en gammel hendelse belønning, en bruker med valgfritt kosmetisk innhold, og en profil som med vilje inneholder en ugyldig arvlig kombinasjon.
Bruk immutable arbeidskopier. Testkjøreren bør aldri overskrive kilden fixtur mens du prøver en migrasjon. Kopier fixturen til en midlertidig arbeidskatalog, registrere sin kontrollsum eller innhold hash, kjøre adapteren og beholde den resulterende utgangen separat. Dette gjør et overraskende resultat til bevis noen andre kan spille om. Det hindrer også en test fra å stille forbedre sin egen inngang til det opprinnelige problemet forsvinner.
Hold spillerdata fra produksjon utenfor en generell mappe med testdata for utvikling. Et historisk testdatakorpus kan være syntetisk, brukes med samtykke, være grundig sladdet eller genereres fra deterministiske scenarioer. Det viktige er at det beholder de strukturelle og semantiske grensetilfellene som betyr noe. Personvern skal ikke være en ettertanke: fjern direkte identifikatorer, enhetsidentifikatorer, kontaktinformasjon, betalingstokener, rå kvitteringer og hemmeligheter før testdata blir bredt tilgjengelige.
Tegn migrasjonsgrafen før du skriver en omformer
Versjonsnumre er ikke en migrasjonsplan. Et spill kan flytte fra 1 til 2, 2 til 3 og 3 til 4, så møte en spiller som har hoppet direkte fra 1 til 4. Det kan sende en hurtigreparasjon som bare endrer en hekket lagerpost, eller pensjonere et felt som gammelt innhold fortsatt forventer. En graf gjør disse valgene synlige: hver node er en lagre skjema eller semantisk versjon; hver kant er en eksplisitt transformasjon eller en intensjon; hver kant har forutsetninger og postbetingelser.
For hver støttet startversjon, avgjør om spillkjeder tilstøtende transformasjoner, bruker en direkte transformasjon, eller krever en tjenesteside oppgradering før klienten laster. Ikke la hoppet versjoner til det som skjer når feltene er fraværende. En kjede kan være tryggere når hvert trinn er liten og testet. En direkte transformasjon kan være tryggere når mellomformater var aldri ment å være observerbare. Begge tilnærmingene trenger klar eierskap og repeterbare fixturer.
Grafen bør inneholde mer enn den serialiserte typen. Ta opp innholdskatalogavhengigheter, konfigurasjonsversjoner, funksjonsflagg som påvirker tolkningen, og gjeldende programversjon. En lagring kan være syntaktisk gjeldende men ugyldig fordi et referanseelement ikke lenger eksisterer eller en regel endret betydning. Dette er kompatibilitetsgrenser, ikke irriterende kanttilfeller.
Gjør lagre-last rundturer observerbare
Når en fixtur går inn i migrasjonsbanen, utfører du en hel rundtur: last den historiske inngangen, trekk den, konstruer in-game-modellen, lagre den ved hjelp av den gjeldende forfatteren, og last deretter den gjeldende utgangen igjen. Den første belastningen kontrollerer om en historisk rekord kan gå inn i systemet. Den andre belastningen kontrollerer om den aktuelle forfatteren opprettet et stabilt, selvkonsistent resultat. Sammenlign tilstanden etter den første og andre belastningen i henhold til semantiske regler, ikke bare rå bytelikhet.
Rå likestilling er ofte feil påstand. Nye standarder kan legges til, feltordre kan endres, tidsstempler kan oppdateres, og samlinger kan motta stabil bestilling. Definere en normalizer for verdier som med vilje ikke er semantiske, deretter sammenligne resten. Normalizeren selv fortjener gjennomgang; det må ikke bli en teppe ignorere liste som skjuler reelle tap. En god sammenligningsrapporter som feltene ble lagt til, fjernet, forvandlet eller med vilje ignoreret.
Testresultatet bør navngi den første ugyldige tilstanden. Hvis en migrasjonskjede har tre overganger, rapporter ikke bare at den endelige belastningen mislyktes. Fang tilstanden etter hvert kontrollpunkt, valider den og stopp ved den tidligste grensen som bryter en invariant. Den lokalisering konverterer en vage \"gammel lagre ødelagt\" rapport til en bestemt migrasjonskant, fixtur og tilstandsforskjell.
Ekspressspillspesifikke invarianter
En generell migrasjonssele kan ikke vite hva progresjon betyr i et bestemt spill. Spillet må gi sine egne invarianter. Skriv dem i språk som forbinder til spillerresultater: et nivå er innenfor det nåværende spekteret; en lagermengde er ikke-negativ og avgrenset; hvert eid element har en kjent definisjon eller en eksplisitt arvlig reserve; en fullført tutorial forblir fullført; valutaen er finitt; en søk referanse tilhører en gjeldende katalog; en rettighet er unik; et verdensfrø og generert verdensstatsavtale.
Separate invarianter i lag. Strukturelle invarianter svarer om nødvendige felt og typer eksisterer. Referensielle invarianter svarer om IDs peker på kjente definisjoner. Domene invarianter svarer om verdier adlyder spillets regler. Sikkerhetsinvarianter svarer om data er finite, avgrenset og trygt å vise. Når en fiksering mislykkes, forteller laget om det trenger en serieendring, katalogadapter, regelsettsbeslutning eller gjenopprettingspolicy.
Bruk deterministiske mutasjoner for å gjøre corpus-arbeidet vanskeligere. Start fra en kjent inventar og fjern med vilje et felt, duplisert en inventar-ID, byt ut en katalogreferanse, hopp over en versjon, reorganisere en handlingsliste eller endre en grensemengde. Hver mutasjon bør ha et forventet resultat: migrere med dokumentert standard, avvise med en diagnostisk kategori, karantæne for gjenoppretting eller kreve en eiergodkjent datareparasjon. \"Det krasjer ikke\" er ikke et tilstrekkelig forventet resultat.
Redusere feilen uten å miste feilen
Store spillertilstander er vanskelig å forstå. Hvis en fixtur inneholder hundrevis av felt og en migrasjon mislykkes, kan en utvikler bruke timer på å lese urelaterte data. Counterexample minimization reduserer fixturen mens den krenkede invarianten bevares. Fjern en feltgruppe, prøv den samme deterministiske migrasjonen og hold fjerningen bare når feilen fortsatt oppstår. Deretter skiller partisjonssamlinger, krymper verdier mot grenser, og redusere handlingshistorikken hvis det gjelder å gjenspille oppførselen.
Reduksjon krever reproduserbarhet. Lås fixturen hash, migrasjonsversjon, adapterversjon, deterministisk frø, relevant konfigurasjonsbilde og forventet invariant. Hvis miljøet endres under hver gjenforsøk, kan en reduserer produsere en mindre tilstand for et annet problem. Behold et replay manifest med de inngangene og det observerte resultatet. Utgangen er ikke bare en mindre fil; det er et regresjonstilfelle noen andre kan utføre.
Generert regresjonsarrangementer bør gå inn i den samme gjennomgangsveien som håndforfattere. Gi hver fixtur et stabilt navn, en kort forklaring på feilen, den invariant den bevarer, og en forventet klassifisering. En regresjonsarrangement er verdifullt fordi det gjør en tidligere overraskende grenserutine. Det bør ikke bli en skjult kilde til produksjonsspillerdata eller en fangst-alle for uforklarlige feil.
Sett øvelsen i CI uten å gjøre det støyende
Kjør en rask representativ undergruppe på hver relevant endring: nåværende migrasjonskanter, høyrisikohistoriske tilstander, og et lite sett av deterministiske mutasjoner. Kjør hele korpusen på en planlagt jobb, frigi kandidat, eller endre som berører seriealisering, progresjon, katalogtolking, skysynkronisering eller lagre-format kode. Skarpt av fixtur familie eller migrasjonskant i stedet for å sende hver test gjennom en lang rekkefølge.
CI-utgang bør være kortfattet, men inspisert. Rapporter fixtur-ID-en, start- og målversjoner, migrasjonskant, invariant- lag, første ugyldige kontrollpunkt, og en bane til den reagerte gjenstanden eller diff. Unngå å skrive ut hele profilinnholdet i logger. Når en feil er ny, beholder den minimale informasjonen som trengs for å representere den lokalt. Når det er forventet, registrerer du at klassifisering slik at en utgivelse ikke stille normaliserer en kjent risiko.
Utgivelsesbeslutningen bør angi hva bevisene betyr. Passing av migrasjonstester støtter et avgrenset krav: den testede corpus og erklærte stier oppfører seg som forventet i det miljøet. De beviser ikke hver spiller lagrer, enhet eller ekstern tjeneste vil oppføre seg identisk. Teams trenger fortsatt å rulle tilbake planer, kundestøttehåndtering og overvåking som respekterer personvern.
Praktisk sjekkliste
- Hold en versjon historisk corpus med scenario etiketter og personvern klassifikasjoner.
- Kopier innganger før migrasjon og bevare hashes for kilde- og utgangsgjenstander.
- Tegne støttede migrasjonskanter, inkludert hopp-versjon policy og eksplisitt avvisning.
- Valider struktur, referanse, domene og sikkerhetsinvarianter etter hvert kontrollpunkt.
- Rundt-tripp migrerte utgangen gjennom den nåværende forfatteren og leseren.
- Bruk deterministiske mutasjoner til å teste manglende felt, duplikatposter, pensjonert innhold og grenseverdier.
- Reduser reproducerbare feil i regresjonsarrangementer med replay manifest.
- Kjør risikofokuserte undergrupper kontinuerlig og full corpus før frigjøringsfølsomme endringer.
- Hold logger og gjenstander omgjort; ikke gjør CI til et spiller-dataarkiv.
Vanlige spørsmål
Trenger vi ekte spillere som sparer for å teste migrasjon?
Nei. Ekte historiske former er nyttige, men corpus kan være syntetisk eller nøye omdøpt. Det som betyr å bevare de vanskelige tilstandskombinasjonene: pensjonert innhold, lang progresjon, avbrutte overganger, valgfrie data og verdier på meningsfulle grenser. Hvis produksjonsdata brukes til å oppdage et kant tilfelle, utledes en sikker fixtur som bare beholder eiendommen under test.
Bør hver gammel versjon bli støttet for alltid?
Ikke nødvendigvis. Støtte er et produkt og driftsbeslutning. Det viktigste er å gjøre grensen eksplisitt: hvilke versjoner migrerer, som krever en tidligere oppdatering, som blir avvist, og hvordan spilleren er informert. En udokumentert utilsiktet sti er det minste sikre alternativet fordi det hverken er pålitelig støttet eller klart nektet.
Kan en serier test erstatte gameplay tester?
Nei. Serializer-tester fastslår at data kan leses og skrives i henhold til deklarerte figurer. Gameplay og domenetests fastslår at den resulterende tilstanden gir mening i det aktuelle regelsettet. En robust migrasjonsøving trenger både, pluss en gjennomgang av innhold og konfigurasjonsreferanser som påvirker betydningen av lagrede verdier.
Hva er Persistiums rolle her?
Persistium er en lokal-første pålitelighet produktfamilie. Retningslinjen i denne noten er praktisk ingeniørråd, ikke et krav om at et offentlig Persistium produkt er tilgjengelig eller at det har diagnostisert ekte kundedata. Dens kontinuerlige retning utforsker typen eksplisitt migrasjon, replay, sammenligning og reduksjon arbeidsflyt beskrevet ovenfor.
