Class SystemConfigurationSettingsCreatorTests

EditMode tests for SystemConfigurationSettingsCreator. Every test targets a fixture asset path under a private temp folder via Input.SettingsAssetPath — the real project's own UnitySystemConfigurationSettings asset(s), if any, are never touched, so these tests stay hermetic regardless of what the project already has configured.

Inheritance
object
SystemConfigurationSettingsCreatorTests
Inherited Members
Namespace: Serenity.SystemConfiguration.Tests.Editor.Builder
Assembly: Serenity.SystemConfiguration.Tests.Editor.dll
Syntax
public class SystemConfigurationSettingsCreatorTests

Constructors

SystemConfigurationSettingsCreatorTests()

Declaration
public SystemConfigurationSettingsCreatorTests()

Methods

Create_ExistingAssetAtExplicitPath_UpdatesItInPlaceInsteadOfCreatingANewOne()

Declaration
public void Create_ExistingAssetAtExplicitPath_UpdatesItInPlaceInsteadOfCreatingANewOne()

Create_ExistingAssetFileRemovedBeforeSecondRun_RollsBackTheAppliedFieldMutation()

Exercises the resolve-or-edit rollback path specifically: an already-existing asset gets its fields mutated in memory, then the pre-persist disk check fails (the settings file was removed from disk after the first Create() call). The mutation must be rolled back to its pre-call values, not just reported as failed — the update-path counterpart of the create-path rollback below.

Declaration
public void Create_ExistingAssetFileRemovedBeforeSecondRun_RollsBackTheAppliedFieldMutation()

Create_ExistingAssetSeededOnEverySerializedField_RestoresThemAll()

Field-by-field regression guard for the generic capture Create(Input) now rolls back through (transaction.TrackExistingAsset), replacing the hand-rolled ExistingAssetSnapshot class this migration deleted. Writes a distinct value into EVERY serialized field of a real UnitySystemConfigurationSettings via reflection — including the UnitySnapshotKeyMap array SystemConfigurationSettingsCreator.ApplyFields only ever rewrites wholesale — forces the update run to fail via the same planted-and-deleted-file technique Create_ExistingAssetFileRemovedBeforeSecondRun_RollsBackTheAppliedFieldMutation() uses, and asserts every field comes back. Proves the capture covers whatever the type declares, not a hand-maintained field list a future field addition could silently outgrow.

Declaration
public void Create_ExistingAssetSeededOnEverySerializedField_RestoresThemAll()

Create_RegisterAsAddressablesFalse_LeavesAddressablesUntouched()

Declaration
public void Create_RegisterAsAddressablesFalse_LeavesAddressablesUntouched()

Create_StaleFolderCacheOnFreshCreation_RollsBackAndLeavesNothing()

The create-path counterpart of the rollback test above: a settings asset write genuinely fails (a stale, cache-valid-but-disk-missing destination folder — the same native UnityEditor.AssetDatabase.CreateAsset(UnityEngine.Object,System.String) failure mode PrefetchPolicyCreatorTests and GameCameraSettingsCreatorTests exercise), forcing Create(Input) to roll back. Asserts the asset genuinely does not exist afterward and that the Addressables entry count is unchanged — the disk-existence guard fires before the asset ever reaches the Addressables retag step, so nothing is left dangling either way.

Declaration
public void Create_StaleFolderCacheOnFreshCreation_RollsBackAndLeavesNothing()

Create_UnderAmbiguousMultipleExistingAssets_CreatesANewAssetWithoutMutatingEitherExisting()

The Create(Input) counterpart of the ambiguity test above. Ambiguity is a warning, never a blocking error (the internal resolution validation's MultipleFoundPaths branch returns before reaching the folder check), so Create must still succeed. Per SettingsAssetAuthoring.ResolveSettingsContext<TSettings>, MultipleFoundPaths != null leaves both Existing and TargetPath null — so Create falls into its ordinary "no existing asset resolved" branch and creates a brand-new THIRD asset under NewSettingsFolderPath, exactly as the wizard's own ambiguity warning documents ("otherwise this run creates yet another one") — it never silently resolves onto either pre-existing ambiguous asset.

Declaration
public void Create_UnderAmbiguousMultipleExistingAssets_CreatesANewAssetWithoutMutatingEitherExisting()

Create_UpdateRunAgainstAnExistingAsset_DoesNotCreateTheOutputFolder()

Regression test for the stray-folder bug this change fixes: an update-in-place run used to unconditionally ensure the run's own output folder even though the resolved existing asset lives entirely elsewhere (an explicit SettingsAssetPath match), leaving an empty folder behind. The second run below resolves the SAME existing asset via Serenity.SystemConfiguration.Tests.Editor.Builder.SystemConfigurationSettingsCreatorTests.SettingsPath but names a different, not-yet-existing Serenity.SystemConfiguration.Tests.Editor.Builder.SystemConfigurationSettingsCreatorTests.ProbeOutputFolder as its NewSettingsFolderPath — exactly the "editing an asset that lives elsewhere while some unrelated output folder is also configured" shape the Create System Configuration Settings wizard reproduced.

Declaration
public void Create_UpdateRunAgainstAnExistingAsset_DoesNotCreateTheOutputFolder()

Create_ValidInput_CreatesAssetWithConfiguredValuesAndAddressablesLabel()

Declaration
public void Create_ValidInput_CreatesAssetWithConfiguredValuesAndAddressablesLabel()

OneTimeTearDown()

Declaration
public void OneTimeTearDown()

SetUp()

Declaration
public void SetUp()

TearDown()

Declaration
public void TearDown()

Validate_EmptyId_ReturnsError()

Declaration
public void Validate_EmptyId_ReturnsError()

Validate_MultipleSettingsAssetsExistInProject_WarnsAboutAmbiguityWithoutBlocking()

Declaration
public void Validate_MultipleSettingsAssetsExistInProject_WarnsAboutAmbiguityWithoutBlocking()

Validate_NullInput_ReturnsMissingInputError()

Declaration
public void Validate_NullInput_ReturnsMissingInputError()

Validate_OutputFolderOutsideAssets_ReturnsError()

An explicit SettingsAssetPath short-circuits the project-wide search entirely (SettingsAssetAuthoring.ResolveSettingsContext<TSettings> just does a direct UnityEditor.AssetDatabase.LoadAssetAtPath``1(System.String) at that exact path), so this stays hermetic and deterministic — it never risks resolving onto the real project's own settings asset, unlike leaving SettingsAssetPath empty would.

Declaration
public void Validate_OutputFolderOutsideAssets_ReturnsError()

Validate_PersistLastSnapshotToDiskWithEmptyJsonFileName_ReturnsError()

Declaration
public void Validate_PersistLastSnapshotToDiskWithEmptyJsonFileName_ReturnsError()

Validate_PollingEnabledWithNonPositiveInterval_WarnsWithoutBlocking()

Declaration
public void Validate_PollingEnabledWithNonPositiveInterval_WarnsWithoutBlocking()

Validate_PrimaryDisplayIndexOutOfRange_WarnsWithoutBlocking()

Declaration
public void Validate_PrimaryDisplayIndexOutOfRange_WarnsWithoutBlocking()

Validate_SyncMapRowWithEmptyTargetKey_WarnsWithoutBlocking()

Distinct from Validate_SyncMapTargetNotFound_WarnsWithoutBlocking(): an empty/whitespace TargetKey is a different branch (never even attempts the project-wide definition lookup) with its own warning message — "has no target GameSettings key assigned" — not the "no UnityGameSettingsDefinition..." wording the unresolved-but-non-empty case produces.

Declaration
public void Validate_SyncMapRowWithEmptyTargetKey_WarnsWithoutBlocking()

Validate_SyncMapTargetNotFound_WarnsWithoutBlocking()

Declaration
public void Validate_SyncMapTargetNotFound_WarnsWithoutBlocking()

Validate_SyncMapTargetResolves_NoWarningForThatRow()

Declaration
public void Validate_SyncMapTargetResolves_NoWarningForThatRow()