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_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_ValidInput_CreatesAssetWithConfiguredValuesAndAddressablesLabel()

Declaration
public void Create_ValidInput_CreatesAssetWithConfiguredValuesAndAddressablesLabel()

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()