Class AdoptedReferenceEndToEndTests

End-to-end EditMode tests adopting REAL shipped systems (never hand-built fixtures) into a shared scratch output root, proving invariant 3 — adopting a later system repairs references an EARLIER adoption run left pointing at package content — through the full SystemAdoptionRunner pipeline: planner, cloner, Id rename, forward remap pass, and back-fill pass, exactly as SettingsAdoptionFlow drives them.

Inheritance
object
AdoptedReferenceEndToEndTests
Inherited Members
Namespace: Serenity.CreateGame.Tests.Editor
Assembly: Serenity.CreateGame.Tests.Editor.dll
Syntax
public class AdoptedReferenceEndToEndTests

Constructors

AdoptedReferenceEndToEndTests()

Declaration
public AdoptedReferenceEndToEndTests()

Methods

AdoptEverythingTwice_TheSecondRunChangesNoAdoptedFile()

A second Adopt All over an already-adopted project must be a no-op: nothing left to clone, and the back-fill finds nothing left to re-point, so not one adopted file changes.

Declaration
public void AdoptEverythingTwice_TheSecondRunChangesNoAdoptedFile()

AdoptEverything_NoAdoptedAssetStillCarriesAShippedId()

Invariant 1, proven across a real multi-system adoption: every ScriptableObject this run cloned must carry an adopted (_Project-suffixed) Id, never the shipped one it was cloned from.

Declaration
public void AdoptEverything_NoAdoptedAssetStillCarriesAShippedId()

AdoptGameSettingsAfterLocalization_WritesNeitherShippedContentNorAnUnaffectedProjectAsset()

The back-fill's write bounds: the shipped originals of everything an adoption touches stay byte-identical, and a project-owned asset that already needs no change is not re-saved.

Declaration
public void AdoptGameSettingsAfterLocalization_WritesNeitherShippedContentNorAnUnaffectedProjectAsset()

AdoptGameSettingsAndMenu_ValidatorReportsNoAdoptedCounterpartWarnings()

The validator's own oracle, restricted to the adopted set (Serenity.CreateGame.Tests.Editor.AdoptedReferenceEndToEndTests.OutputRoot): once a system's referenced counterpart is also adopted, nothing under the output root may still point at a shipped asset that has an adopted sibling.

Declaration
public void AdoptGameSettingsAndMenu_ValidatorReportsNoAdoptedCounterpartWarnings()

AdoptGameSettingsAndMenu_ValidatorReportsNoDanglingReferencesForTheAdoptedSet()

The validator's dangling-reference oracle, restricted to the adopted set — measured against the SHIPPED BASELINE rather than an absolute zero: the shipped originals of the adopted set may already carry a genuine authoring defect (as ControlsSettingsMenu.asset does, documented in FoundationReferenceContractsTests.KnownShippedDefects) that adoption itself did nothing to cause and cannot repair. What adoption must never do is INTRODUCE a new dangling reference the shipped original did not already have, so this asserts the adopted set's dangling findings (by field + value — the same signature identifies a reference across a shipped asset and its clone, since an unresolved reference is left byte-for-byte as authored) are a SUBSET of the baseline measured on the shipped sources before adoption ran.

Declaration
public void AdoptGameSettingsAndMenu_ValidatorReportsNoDanglingReferencesForTheAdoptedSet()

AdoptGameSettingsThenLocalization_BothLanguageKeys_PointAtTheAdoptedSettings()

The forward-pass order: the two language settings are adopted first, so the localization clone's own remap resolves both keys without any back-fill.

Declaration
public void AdoptGameSettingsThenLocalization_BothLanguageKeys_PointAtTheAdoptedSettings()

AdoptGameSettingsThenUi_ScaleAndFontSizeKeys_PointAtTheAdoptedSettings()

The forward-pass counterpart of AdoptUiThenMenu_UiSettingsInitialViewId_PointsAtTheAdoptedMainMenu(): here the referenced systems (the two game settings) are adopted BEFORE the owner (Ui), so their adopted counterparts already exist in the index by the time Ui's own forward pass walks its clone — no back-fill needed at all.

Declaration
public void AdoptGameSettingsThenUi_ScaleAndFontSizeKeys_PointAtTheAdoptedSettings()

AdoptLocalizationAlone_BothLanguageKeys_StillNameTheShippedSettings()

Only the holder is adopted: neither language setting has an adopted counterpart, so both keys must stay exactly as shipped and keep resolving to the shipped settings — never be suffixed into an Id nothing carries.

Declaration
public void AdoptLocalizationAlone_BothLanguageKeys_StillNameTheShippedSettings()

AdoptLocalizationAndGameSettingsTogether_BothLanguageKeys_PointAtTheAdoptedSettings()

Both sides in ONE plan, the shape Adopt All produces when a single run covers the pair.

Declaration
public void AdoptLocalizationAndGameSettingsTogether_BothLanguageKeys_PointAtTheAdoptedSettings()

AdoptLocalizationThenGameSettings_BothLanguageKeys_PointAtTheAdoptedSettings()

The back-fill order: the reference HOLDER is adopted first, so nothing resolves during its own run; adopting the two language settings afterwards must repair both of its keys.

Declaration
public void AdoptLocalizationThenGameSettings_BothLanguageKeys_PointAtTheAdoptedSettings()

AdoptMenu_ProjectOwnedAssetOutsideTheOutputRoot_IsNeverTouchedByTheBackfill()

The back-fill's own blast-radius guard: a project-owned asset that hosts a contracted IFoundationSettings type but lives OUTSIDE this adoption's output root must never be touched, even though it carries the exact same stale reference the in-scope oracle above proves gets repaired.

Declaration
public void AdoptMenu_ProjectOwnedAssetOutsideTheOutputRoot_IsNeverTouchedByTheBackfill()

AdoptSplashTaskWithItsGuidArgumentRoots_AdoptedTasksStringArgPointsAtTheAdoptedCutscene()

Reproduces the owner's reported defect directly: the real shipped PlayInitSplashScreen task's stringArgs[0] is the real shipped InitSplash cutscene's Guid — a reference UnityEditor.AssetDatabase.GetDependencies(System.String,System.Boolean) can never see, since it is a plain string. Rooting the plan at the task PLUS Serenity.CreateGame.Infrastructure.Editor.Wiring.BootTaskGuidArgumentRoots.ResolveReferencedAssetPaths(System.Collections.Generic.IReadOnlyList{System.String})'s own result (exactly what ProjectPipelineAdoption does) must adopt the cutscene alongside the task and re-point the adopted task's argument at the adopted cutscene's own new Guid — never leave it pointing at the shipped Guid, which is what produced the owner's "Definition '...' not found" failure at boot.

Declaration
public void AdoptSplashTaskWithItsGuidArgumentRoots_AdoptedTasksStringArgPointsAtTheAdoptedCutscene()

AdoptSystemConfigurationAndGameLanguageTogether_SyncRowTargetKey_NamesTheAdoptedSetting()

The OS-language sync row names a game setting by Id, and the runtime looks it up by exact key: adopting both sides in one run must leave the adopted row naming the adopted setting, or syncing the player's OS language into the game language silently misses.

Declaration
public void AdoptSystemConfigurationAndGameLanguageTogether_SyncRowTargetKey_NamesTheAdoptedSetting()

AdoptSystemConfigurationThenGameLanguage_SyncRowTargetKey_NamesTheAdoptedSetting()

The back-fill order of the same pair: the sync-map holder is adopted first, so nothing resolves during its own run; adopting the setting afterwards must repair the row.

Declaration
public void AdoptSystemConfigurationThenGameLanguage_SyncRowTargetKey_NamesTheAdoptedSetting()

AdoptUiThenMenu_UiSettingsInitialViewId_PointsAtTheAdoptedMainMenu()

The plan's own retroactive-repair oracle: the shipped UiSettings.asset carries InitialViewId: MainMenu, a plain string never in Ui's own dependency closure. Adopting Ui alone leaves it stale (Menu was not adopted yet, so the index has no adopted MainMenu to resolve against); adopting Menu afterwards, into the SAME output root, must back-fill the already-adopted UiSettings clone to point at the newly adopted MainMenu.

Declaration
public void AdoptUiThenMenu_UiSettingsInitialViewId_PointsAtTheAdoptedMainMenu()

AdoptedProjectStillNamingTheShippedLanguageSettings_IsReportedThenRepairedByTheNextAdoption()

A project already carrying the mis-matched state — its own localization settings still naming the shipped language settings while adopted counterparts exist — is reported by the validator, and the next adoption action into the same output root repairs it.

Declaration
public void AdoptedProjectStillNamingTheShippedLanguageSettings_IsReportedThenRepairedByTheNextAdoption()

SetUp()

Declaration
public void SetUp()

TearDown()

Declaration
public void TearDown()