Namespace Serenity.StructuredPersistence.Tests.Editor

Classes

CoverageRunnerDriverParityTests

Keeps Tools/CoverageRunner/CoverageRunner.csproj honest against DatabaseDriverManifests.

DatabaseDriverDoctorWindowTests

Proves the doctor survives contact with the real project: the menu item resolves, the window constructs, and the scan-then-inspect path runs against whatever is actually on disk without throwing. Compiling proves none of that.

DatabaseDriverInspectorTests

Behaviour of the driver check. The inspector takes the installed paths and the defined symbols as arguments, so every case here is a plain list — no filesystem, no editor state, no project mutation.

ProviderAsmdefDriverParityTests

Keeps the four provider assembly definitions honest against DatabaseDriverManifests.

SettingsAssetAuthoringValidateResolutionTests

EditMode tests for ValidateResolution<TSettings>(SettingsResolution<TSettings>, string, SerenityCreationValidationResult) — the pass six by-type settings creators used to copy. Nothing here touches the AssetDatabase: the pass reads a SettingsAssetAuthoring.SettingsResolution<TSettings> the caller already holds, so an in-memory one is the whole input.

SettingsAssetRelocationTests

EditMode tests for SettingsAssetRelocation — the shared move-out-of-package engine every by-type settings creator adopting SerenityWizardTargetAsset.MoveOutOfPackage shares. Built on real assets on disk, mirroring the fixture discipline of Serenity.UnityGlobal.Tests.Editor.SerenityPackageContentRelocatorTests: the package-content fixture lives under a throwaway folder nested inside Serenity.Global.Infrastructure.Editor.SerenityEditorPaths.AssetsRoot, wiped in both SetUp() and TearDown() via Serenity.Global.Infrastructure.Editor.Validation.References.SerenitySafeDeleteScope.

SettingsAssetResolutionTestSettings

A throwaway IFoundationSettings asset type for SettingsAssetResolutionTests. Lives in its own same-named file so Unity can bind its script when the tests create it as an asset, and is private to this suite so the by-Id passes it drives never see another suite's leftovers (the same reason SerenityAssetIdLookupTestSettings gives).

SettingsAssetResolutionTests

EditMode tests for SettingsAssetResolution: both the by-Id-in-folder resolve-or-create every multi-asset creation engine shares, and the by-path resolve-or-create every single project-wide settings wizard shares. Built on real assets on disk, because the contract is about what the AssetDatabase resolves and what actually lands on disk — neither survives an in-memory double.

Every test drives a real Serenity.Global.Infrastructure.Editor.SerenityAssetCreationTransaction and rolls it back in teardown, so nothing is ever registered with the project's Addressables settings.

SingletonSettingsCreationEngineTestSettings

A throwaway settings asset type for SingletonSettingsCreationEngineTests. Lives in its own same-named file so Unity can bind its script when the tests create it as an asset, and carries a Title the engine's ApplyFields writes — a restore is only observable through a field, so an Id/Guid-only fixture could not show one.

SingletonSettingsCreationEngineTests

EditMode tests for SingletonSettingsCreationEngine<TSettings, TInput, TResult>, driven through a scratch subclass. Built on real assets under a private temp folder wiped in TearDown(), because the contract is about what lands on disk, what the Addressables settings end up holding, and what a rollback puts back — none of which survives an in-memory double. Only the registration test opts into Addressables, and it removes the entry it created.

StructuredBackendAssetInstallerTests

EditMode tests for StructuredBackendAssetInstaller, built on real assets on disk because the contract is about what survives on disk when a run fails — which no in-memory double can answer.

The first test is the one that matters: it is the reason this pipeline was collapsed into a single implementation. Four creators each carried their own copy of the park/replace/restore trio, and the asset that copy holds is the user's OWN backend, moved rather than copied — so a rollback-ordering mistake in any one of them destroys real project data with no second copy to recover from.