Class GameCameraSettingsCreatorTests

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

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

Constructors

GameCameraSettingsCreatorTests()

Declaration
public GameCameraSettingsCreatorTests()

Methods

ApplyInputToDraft_EveryAssetFieldHasALikeNamedInputFieldOrIsExplicitlyExcluded()

Declaration
public void ApplyInputToDraft_EveryAssetFieldHasALikeNamedInputFieldOrIsExplicitlyExcluded()

Create_AssetAlreadyExistsAtTheExactPathButExistingAssetNotSet_RefusesAndLeavesItByteIdentical()

Companion to Validate_AssetAlreadyExistsAtTheExactPathButExistingAssetNotSet_IsInvalid(): Create(Input) must refuse the same request end to end, leaving the unrelated asset byte-identical.

Declaration
public void Create_AssetAlreadyExistsAtTheExactPathButExistingAssetNotSet_RefusesAndLeavesItByteIdentical()

Create_EmptyId_FailsWithoutCreatingAnyAsset()

Declaration
public void Create_EmptyId_FailsWithoutCreatingAnyAsset()

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.

Asserts against settingsBeforeSecondRun — the SAME C# object instance resolved right after the first, successful Create() call — rather than re-resolving via a second UnityEditor.AssetDatabase.LoadAssetAtPath``1(System.String) call after the failing one. The rollback's own UnityEditor.AssetDatabase.Refresh could plausibly notice the deleted backing file and drop the GUID-to-asset mapping; reading the already-held reference's fields sidesteps that uncertainty entirely, since GameCameraSettingsCreator's restore mutates the very instance the wizard already resolved, not a freshly re-loaded one.

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 UnityGameCameraSettings via reflection — including the UnityEngine.LayerMask-typed ExcludeLayerMask, which the deleted snapshot instead stored as a plain int — 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_NestedOutputFolderDoesNotExistYet_CreatesTheFullChainAndTheAsset()

Declaration
public void Create_NestedOutputFolderDoesNotExistYet_CreatesTheFullChainAndTheAsset()

Create_PathOnlyCallerResolvedThroughResolveExistingAssetFromPathWithNothingAtThePath_CreatesFresh()

ResolveExistingAssetFromPath(Input) is a no-op when nothing exists at SettingsAssetPath yet — a path-only caller aiming at a genuinely free path still creates fresh, never blocked by a phantom identity.

Declaration
public void Create_PathOnlyCallerResolvedThroughResolveExistingAssetFromPathWithNothingAtThePath_CreatesFresh()

Create_PathOnlyCallerResolvedThroughResolveExistingAssetFromPath_UpdatesInPlace()

Companion end-to-end proof: Create(Input) edits the SAME asset in place, creating nothing new.

Declaration
public void Create_PathOnlyCallerResolvedThroughResolveExistingAssetFromPath_UpdatesInPlace()

Create_RegisterAsAddressablesFalse_LeavesAddressablesUntouched()

Declaration
public void Create_RegisterAsAddressablesFalse_LeavesAddressablesUntouched()

Create_RegisterAsAddressablesTrue_RegistersTheCreatedAsset()

Declaration
public void Create_RegisterAsAddressablesTrue_RegistersTheCreatedAsset()

Create_StaleFolderCacheOnFreshCreation_RollsBackAndLeavesNothing()

Declaration
public void Create_StaleFolderCacheOnFreshCreation_RollsBackAndLeavesNothing()

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.GameCamera.Tests.Editor.Builder.GameCameraSettingsCreatorTests.SettingsPath but names a different, not-yet-existing Serenity.GameCamera.Tests.Editor.Builder.GameCameraSettingsCreatorTests.ProbeOutputFolder as its NewSettingsFolderPath — exactly the "editing an asset that lives elsewhere while some unrelated output folder is also configured" shape the Create Camera Settings wizard reproduced.

Declaration
public void Create_UpdateRunAgainstAnExistingAsset_DoesNotCreateTheOutputFolder()

Create_ValidInput_CreatesAssetWithConfiguredValues()

Declaration
public void Create_ValidInput_CreatesAssetWithConfiguredValues()

OneTimeTearDown()

Declaration
public void OneTimeTearDown()

SetUp()

Declaration
public void SetUp()

TearDown()

Declaration
public void TearDown()

Validate_AssetAlreadyExistsAtTheExactPathButExistingAssetNotSet_IsInvalid()

An unconfigured ExistingAsset (the correct value for a genuine create) must still refuse landing on an asset this call never named — proving the collision guard runs unconditionally, with no flag a headless caller could forget to set.

Declaration
public void Validate_AssetAlreadyExistsAtTheExactPathButExistingAssetNotSet_IsInvalid()

Validate_AssetAlreadyExistsAtTheExactPath_IsValidForAnUpdateInsteadOfAnError()

Declaration
public void Validate_AssetAlreadyExistsAtTheExactPath_IsValidForAnUpdateInsteadOfAnError()

Validate_EmptyId_ReturnsError()

Declaration
public void Validate_EmptyId_ReturnsError()

Validate_MultipleSettingsAssetsExistInProject_WarnsAboutAmbiguityWithoutBlocking()

Declaration
public void Validate_MultipleSettingsAssetsExistInProject_WarnsAboutAmbiguityWithoutBlocking()

Validate_PathOnlyCallerResolvedThroughResolveExistingAssetFromPath_IsValidForAnUpdate()

A path-only caller — one with no live ExistingAsset reference, a headless tool or a recipe importer that only carries the path — states its own identity assertion through ResolveExistingAssetFromPath(Input) before validating, and the update then proceeds exactly like a caller that resolved the reference itself.

Declaration
public void Validate_PathOnlyCallerResolvedThroughResolveExistingAssetFromPath_IsValidForAnUpdate()

Validate_TwoProjectCopiesAndNoAssetChosen_WarnsInTheAuthorsTermsNamingBothCopies()

Two camera settings assets the project owns are an ambiguity the author resolves by picking one in the wizard. The warning says so in the author's terms: it names both assets, never the code field a caller would assign, never the settings type's code name, and never a third asset the run cannot create.

Declaration
public void Validate_TwoProjectCopiesAndNoAssetChosen_WarnsInTheAuthorsTermsNamingBothCopies()