DP44/enriched-qwen3-coder-next/DataPRO/UnitTest/DatabaseUnitTesting/Properties.md

source_files, generated_at, model, schema_version, sha256

source_files	generated_at	model	schema_version	sha256
DataPRO/UnitTest/DatabaseUnitTesting/Properties/Settings.Designer.cs	2026-04-16T03:51:52.660365+00:00	Qwen/Qwen3-Coder-Next-FP8	1	f8ee505a9bbaa788

Properties

1. Purpose

This module defines strongly-typed application and user settings for the DatabaseUnitTesting project, specifically managing database connection and naming configuration used during unit testing. It leverages .NET’s ApplicationSettingsBase to provide compile-time-safe access to configuration values—such as the test database connection string, database name, and snapshot name—enabling consistent and maintainable test environment setup without hardcoding values.

2. Public Interface

The class Settings (fully qualified: DatabaseUnitTesting.Properties.Settings) exposes the following members:

• public static Settings Default { get; }
  A thread-safe singleton accessor for the settings instance. Returns the single shared Settings object used throughout the application.

• public string ConnectionString { get; }
  An application-scoped read-only string property providing the SQL Server connection string for the unit test database. Default value:
  "Data Source=FAJITA\\DEV_SQL;Initial Catalog=DataPRO_UnitTest;Integrated Security=False;Persist Security Info=True;User ID=sa;Password=!!QQAAZZxxssww22;Connect Timeout=15;Encrypt=False;TrustServerCertificate=True;ApplicationIntent=ReadWrite;MultiSubnetFailover=False"
  Marked with SpecialSettingAttribute.SpecialSetting.ConnectionString, indicating it is intended for ADO.NET connection usage.

• public string DBName { get; set; }
  A user-scoped read-write string property for the target database name used in tests. Default value: "DataPRO_UnitTest".

• public string DBSnapshot { get; set; }
  A user-scoped read-write string property for the database snapshot name used during testing (likely for restoring state between test runs). Default value: "DataPRO_UnitTestSnapshot".

3. Invariants

• The ConnectionString property is application-scoped and immutable at runtime—its value cannot be changed programmatically after initialization.
• DBName and DBSnapshot are user-scoped and mutable; changes persist only for the current user and require explicit saving (e.g., via Settings.Default.Save()) to be persisted across sessions.
• The Default property returns a synchronized (thread-safe) instance, implying safe concurrent read access.
• The ConnectionString value is validated at design time by the Settings Designer as a well-formed connection string, but no runtime validation is present in this file.

4. Dependencies

• Depends on:
  • System.Configuration (for ApplicationSettingsBase, attributes like ApplicationScopedSettingAttribute, SpecialSettingAttribute, etc.)
  • System.Diagnostics (for DebuggerNonUserCodeAttribute)
  • System.Runtime.CompilerServices (for CompilerGeneratedAttribute)
• Used by: Any code in the DatabaseUnitTesting project (or referencing it) that needs to access test database configuration—e.g., test setup/teardown logic, database initialization utilities, or test harnesses that restore snapshots or connect to the test database.

5. Gotchas

• Hardcoded credentials: The default ConnectionString embeds a plaintext password (User ID=sa;Password=!!QQAAZZxxssww22). This is a security risk and should be replaced with secure credential storage (e.g., Windows Credential Manager, Azure Key Vault) in production or shared environments.
• Assumed SQL Server instance: The Data Source=FAJITA\DEV_SQL implies a specific named instance; this will fail on machines without that instance unless overridden in user settings or config.
• Integrated Security=False: Explicit use of SQL authentication (not Windows auth) may not align with security policies in some environments.
• No validation logic: The settings class does not validate that DBName or DBSnapshot refer to actual databases or that DBSnapshot is a valid snapshot name. Errors will surface only at runtime during database operations.
• Auto-generated file: As indicated by the <auto-generated> header, manual edits will be overwritten on regeneration (e.g., after modifying settings in Visual Studio’s designer).