New-SqlDscDatabase: Add more properties#2356
Conversation
|
Caution Review failedThe pull request is closed. WalkthroughAdds New-SqlDscDatabase with many creation-time parameters mapping SMO Database properties; converts many boolean database-property parameters across New-/Set-/Test-SqlDscDatabase to SwitchParameter or SMO enum types, updates comparison/conversion logic, extends SMO stubs, and updates unit and integration tests. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Possibly related PRs
Pre-merge checks✅ Passed checks (5 passed)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (3)
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1 (2)
77-85: Mocked SMO properties and new behavior tests for additional database options look consistent.The extra
Add-Memberproperties on the mockedMicrosoft.SqlServer.Management.Smo.Databaseobject (AutoClose, AutoShrink, PageVerify, ReadOnly, MaxDop, TargetRecoveryTime, ContainmentType, DelayedDurability) line up with the new parameters exercised in the three addedItblocks. This gives good coverage thatNew-SqlDscDatabaseactually flows boolean, integer, and enum-style properties onto the created database object.Two small follow‑ups to consider:
- Ensure the SMO stubs in
SMO.csalso declare these properties so the tests are aligned with the stub type surface and not only with PS-added note properties.- Given
CatalogCollationis creation‑only, it may be worth adding a focused test that verifies it is applied at creation time (e.g., asserted on the mock before or immediately after theCreate()call) to guard against accidental regressions in that special case.Based on learnings, please double-check that the SMO stub types in
SMO.csexpose the same property set and thatCatalogCollationis covered by at least one behavioral test.Also applies to: 132-159
222-267: Parameter-set validation for the Database set is pragmatic and mostly aligned with guidelines.The updated
'Parameter validation'context now:
- Verifies that the
Databaseparameter set exists and has the expected core parameters (includingCatalogCollation,IsLedger,FileGroup).- Separately checks that representative Boolean/Integer/String/Enum property parameters (e.g.,
AutoClose,MaxDop,ContainmentType) are present in theDatabaseparameter set.This is a reasonable compromise versus asserting the full
ParameterListAsString, which would be unwieldy given the large number of properties. The Snapshot parameter set still uses the full string check, so the pattern is covered where it’s tractable.If you want to make this explicit for future maintainers, consider adding a short comment above this test explaining that we intentionally validate by parameter membership instead of
ParameterListAsStringdue to the size of the Database parameter set.tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1 (1)
92-202: Good coverage for new properties; align cleanup with-ErrorAction 'Stop'The new integration tests do a nice job exercising boolean (
AutoClose,AutoShrink,ReadOnly), integer (TargetRecoveryTime), enum (PageVerify,UserAccess), and mixed properties during creation and verifying both the returned SMO object and the actual database.One small consistency tweak: in the
finallyblocks of the new tests you call:$null = Remove-SqlDscDatabase -DatabaseObject $dbToRemove -Forcewhereas other cleanup paths in this file use
-ErrorAction 'Stop'. To follow the integration-test guidelines and fail fast when cleanup cannot remove the test DB, consider:- $null = Remove-SqlDscDatabase -DatabaseObject $dbToRemove -Force + $null = Remove-SqlDscDatabase -DatabaseObject $dbToRemove -Force -ErrorAction 'Stop'for each
finallyblock.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
CHANGELOG.md(1 hunks)source/Public/New-SqlDscDatabase.ps1(3 hunks)tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1(1 hunks)tests/Unit/Public/New-SqlDscDatabase.Tests.ps1(3 hunks)
🧰 Additional context used
📓 Path-based instructions (16)
**/*.ps1
📄 CodeRabbit inference engine (.github/instructions/SqlServerDsc-guidelines.instructions.md)
**/*.ps1: Format public commands as{Verb}-SqlDsc{Noun}following PowerShell naming conventions
Format private functions as{Verb}-{Noun}following PowerShell naming conventions
Files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1tests/Unit/Public/New-SqlDscDatabase.Tests.ps1source/Public/New-SqlDscDatabase.ps1
**/tests/Integration/**/*.ps1
📄 CodeRabbit inference engine (.github/instructions/SqlServerDsc-guidelines.instructions.md)
Integration tests: use
Connect-SqlDscDatabaseEnginefor SQL Server DB session with correct CI credentials, and always follow withDisconnect-SqlDscDatabaseEngine
Files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1
tests/Integration/Commands/*.Integration.Tests.ps1
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines-integration-tests.instructions.md)
Location for Commands integration tests:
tests/Integration/Commands/{CommandName}.Integration.Tests.ps1Integration tests for commands should be located in
tests/Integration/Commands/{CommandName}.Integration.Tests.ps1
Files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1
tests/Integration/**/*.Integration.Tests.ps1
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines-integration-tests.instructions.md)
tests/Integration/**/*.Integration.Tests.ps1: Integration tests must not use mocking - use real environment only
Integration tests must cover all scenarios and code paths
UseGet-ComputerNamefor computer names in CI environments
AvoidExpectedMessageparameter forShould -Throwassertions in integration tests
Call commands with-Forceparameter where applicable to avoid prompting
Use-ErrorAction 'Stop'on commands so failures surface immediately
Integration tests must include the required setup block with BeforeDiscovery that imports DscResource.Test module and BeforeAll that imports the module being tested
Files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1
**/*.[Tt]ests.ps1
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines-pester.instructions.md)
**/*.[Tt]ests.ps1: All public commands, private functions and classes must have unit tests
All public commands and class-based resources must have integration tests
Use Pester v5 syntax only
Test code only insideDescribeblocks
Assertions only inItblocks
Never test verbose messages, debug messages or parameter binding behavior
Pass all mandatory parameters to avoid prompts
InsideItblocks, assign unused return objects to$null(unless part of pipeline)
Tested entity must be called from within theItblocks
Keep results and assertions in sameItblock
Avoid try-catch-finally for cleanup, useAfterAllorAfterEach
Avoid unnecessary remove/recreate cycles
OneDescribeblock per file matching the tested entity name
Contextdescriptions start with 'When'
Itdescriptions start with 'Should', must not contain 'when'
Mock variables prefix: 'mock'
Public commands: Never useInModuleScope(unless retrieving localized strings or creating an object using an internal class)
Private functions/class resources: Always useInModuleScope
Each class method = separateContextblock
Each scenario = separateContextblock
Use nestedContextblocks for complex scenarios
Mocking inBeforeAll(BeforeEachonly when required)
Setup/teardown inBeforeAll,BeforeEach/AfterAll,AfterEachclose to usage
Spacing between blocks, arrange, act, and assert for readability
PascalCase:Describe,Context,It,Should,BeforeAll,BeforeEach,AfterAll,AfterEach
Use-BeTrue/-BeFalsenever-Be $true/-Be $false
Never useAssert-MockCalled, useShould -Invokeinstead
NoShould -Not -Throw- invoke commands directly
Never add an empty-MockWithblock
Omit-MockWithwhen returning$null
Set$PSDefaultParameterValuesforMock:ModuleName,Should:ModuleName,InModuleScope:ModuleName
Omit-ModuleNameparameter on Pester commands
Never useMockinsideInModuleScope-block
Never useparam()inside-MockWithscriptblock...
Files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
⚙️ CodeRabbit configuration file
**/*.[Tt]ests.ps1: # Tests GuidelinesCore Requirements
- All public commands, private functions and classes must have unit tests
- All public commands and class-based resources must have integration tests
- Use Pester v5 syntax only
- Test code only inside
Describeblocks- Assertions only in
Itblocks- Never test verbose messages, debug messages or parameter binding behavior
- Pass all mandatory parameters to avoid prompts
Requirements
- Inside
Itblocks, assign unused return objects to$null(unless part of pipeline)- Tested entity must be called from within the
Itblocks- Keep results and assertions in same
Itblock- Avoid try-catch-finally for cleanup, use
AfterAllorAfterEach- Avoid unnecessary remove/recreate cycles
Naming
- One
Describeblock per file matching the tested entity nameContextdescriptions start with 'When'Itdescriptions start with 'Should', must not contain 'when'- Mock variables prefix: 'mock'
Structure & Scope
- Public commands: Never use
InModuleScope(unless retrieving localized strings or creating an object using an internal class)- Private functions/class resources: Always use
InModuleScope- Each class method = separate
Contextblock- Each scenario = separate
Contextblock- Use nested
Contextblocks for complex scenarios- Mocking in
BeforeAll(BeforeEachonly when required)- Setup/teardown in
BeforeAll,BeforeEach/AfterAll,AfterEachclose to usage- Spacing between blocks, arrange, act, and assert for readability
Syntax Rules
- PascalCase:
Describe,Context,It,Should,BeforeAll,BeforeEach,AfterAll,AfterEach- Use
-BeTrue/-BeFalsenever-Be $true/-Be $false- Never use
Assert-MockCalled, useShould -Invokeinstead- No
Should -Not -Throw- invoke commands directly- Never add an empty
-MockWithblock- Omit
-MockWithwhen returning$null- Set
$PSDefaultParameterValuesforMock:ModuleName,Should:ModuleName, `...
Files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
**/*.{ps1,psm1,psd1}
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines-powershell.instructions.md)
**/*.{ps1,psm1,psd1}: Use descriptive names with 3+ characters and no abbreviations for functions, variables, and identifiers
Functions: Use PascalCase with Verb-Noun format using approved verbs
Parameters: Use PascalCase
Variables: Use camelCase
Keywords: Use lower-case
Classes: Use PascalCase
Include scope for script/global/environment variables:$script:,$global:,$env:
Use 4 spaces for indentation (no tabs)
Use one space around operators:$a = 1 + 2
Use one space between type and variable:[String] $name
Use one space between keyword and parenthesis:if ($condition)
No spaces on empty lines
Try to limit lines to 120 characters
Newline before opening brace (except variable assignments)
One newline after opening brace
Two newlines after closing brace (one if followed by another brace or continuation)
Use single quotes unless variable expansion is needed:'text'vs"text $variable"
Single-line arrays:@('one', 'two', 'three'); multi-line: each element on separate line with proper indentation
Do not use the unary comma operator (,) in return statements to force an array
Empty hashtables:@{}; each property on separate line with proper indentation; use PascalCase for properties
Single-line comments:# Comment(capitalized, on own line); multi-line:<# Comment #>format with opening/closing brackets on own line
Do not include commented-out code
Always add comment-based help to all functions and scripts with SYNOPSIS, DESCRIPTION (40+ chars), PARAMETER, and EXAMPLE sections
Comment-based help indentation: keywords 4 spaces, text 8 spaces
Include examples in comment-based help for all parameter sets and combinations
INPUTS section in comment-based help: list each pipeline-accepted type (one per line) with 1-line description, repeat keyword for each input type
OUTPUTS section in comment-based help: list each return type (one per line) with 1-line description, repeat keyword for each output type; must match both[OutputType()]and actual ret...
Files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1tests/Unit/Public/New-SqlDscDatabase.Tests.ps1source/Public/New-SqlDscDatabase.ps1
**
⚙️ CodeRabbit configuration file
**: # DSC Community GuidelinesTerminology
- Command: Public command
- Function: Private function
- Resource: DSC class-based resource
Build & Test Workflow Requirements
- Run PowerShell script files from repository root
- Setup build and test environment (once per
pwshsession):./build.ps1 -Tasks noop- Build project before running tests:
./build.ps1 -Tasks build- Always run tests in new
pwshsession:Invoke-Pester -Path @({test paths}) -Output DetailedFile Organization
- Public commands:
source/Public/{CommandName}.ps1- Private functions:
source/Private/{FunctionName}.ps1- Classes:
source/Classes/{DependencyGroupNumber}.{ClassName}.ps1- Enums:
source/Enum/{DependencyGroupNumber}.{EnumName}.ps1- Unit tests:
tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1- Integration tests:
tests/Integration/Commands/{CommandName}.Integration.Tests.ps1Requirements
- Follow instructions over existing code patterns
- Follow PowerShell style and test guideline instructions strictly
- Always update CHANGELOG.md Unreleased section
- Localize all strings using string keys; remove any orphaned string keys
- Check DscResource.Common before creating private functions
- Separate reusable logic into private functions
- DSC resources should always be created as class-based resources
- Add unit tests for all commands/functions/resources
- Add integration tests for all public commands and resources
Files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1CHANGELOG.mdtests/Unit/Public/New-SqlDscDatabase.Tests.ps1source/Public/New-SqlDscDatabase.ps1
{**/*.ps1,**/*.psm1,**/*.psd1}
⚙️ CodeRabbit configuration file
{**/*.ps1,**/*.psm1,**/*.psd1}: # PowerShell GuidelinesNaming
- Use descriptive names (3+ characters, no abbreviations)
- Functions: PascalCase with Verb-Noun format using approved verbs
- Parameters: PascalCase
- Variables: camelCase
- Keywords: lower-case
- Classes: PascalCase
- Include scope for script/global/environment variables:
$script:,$global:,$env:File naming
- Class files:
###.ClassName.ps1format (e.g.001.SqlReason.ps1,004.StartupParameters.ps1)Formatting
Indentation & Spacing
- Use 4 spaces (no tabs)
- One space around operators:
$a = 1 + 2- One space between type and variable:
[String] $name- One space between keyword and parenthesis:
if ($condition)- No spaces on empty lines
- Try to limit lines to 120 characters
Braces
- Newline before opening brace (except variable assignments)
- One newline after opening brace
- Two newlines after closing brace (one if followed by another brace or continuation)
Quotes
- Use single quotes unless variable expansion is needed:
'text'vs"text $variable"Arrays
- Single line:
@('one', 'two', 'three')- Multi-line: each element on separate line with proper indentation
- Do not use the unary comma operator (
,) in return statements to force
an arrayHashtables
- Empty:
@{}- Each property on separate line with proper indentation
- Properties: Use PascalCase
Comments
- Single line:
# Comment(capitalized, on own line)- Multi-line:
<# Comment #>format (opening and closing brackets on own line), and indent text- No commented-out code
Comment-based help
- Always add comment-based help to all functions and scripts
- Comment-based help: SYNOPSIS, DESCRIPTION (40+ chars), PARAMETER, EXAMPLE sections before function/class
- Comment-based help indentation: keywords 4 spaces, text 8 spaces
- Include examples for all parameter sets and combinations
- INPUTS: List each pipeline‑accepted type (one per line) with a 1‑line description...
Files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1tests/Unit/Public/New-SqlDscDatabase.Tests.ps1source/Public/New-SqlDscDatabase.ps1
tests/[iI]ntegration/**/*.[iI]ntegration.[tT]ests.ps1
⚙️ CodeRabbit configuration file
tests/[iI]ntegration/**/*.[iI]ntegration.[tT]ests.ps1: # Integration Tests GuidelinesRequirements
- Location Commands:
tests/Integration/Commands/{CommandName}.Integration.Tests.ps1- Location Resources:
tests/Integration/Resources/{ResourceName}.Integration.Tests.ps1- No mocking - real environment only
- Cover all scenarios and code paths
- Use
Get-ComputerNamefor computer names in CI- Avoid
ExpectedMessageforShould -Throwassertions- Only run integration tests in CI unless explicitly instructed.
- Call commands with
-Forceparameter where applicable (avoids prompting).- Use
-ErrorAction 'Stop'on commands so failures surface immediatelyRequired Setup Block
[System.Diagnostics.CodeAnalysis.SuppressMessageAttribute('PSUseDeclaredVarsMoreThanAssignments', '', Justification = 'Suppressing this rule because Script Analyzer does not understand Pester syntax.')] param () BeforeDiscovery { try { if (-not (Get-Module -Name 'DscResource.Test')) { # Assumes dependencies have been resolved, so if this module is not available, run 'noop' task. if (-not (Get-Module -Name 'DscResource.Test' -ListAvailable)) { # Redirect all streams to $null, except the error stream (stream 2) & "$PSScriptRoot/../../../build.ps1" -Tasks 'noop' 3>&1 4>&1 5>&1 6>&1 > $null } # If the dependencies have not been resolved, this will throw an error. Import-Module -Name 'DscResource.Test' -Force -ErrorAction 'Stop' } } catch [System.IO.FileNotFoundException] { throw 'DscResource.Test module dependency not found. Please run ".\build.ps1 -ResolveDependency -Tasks noop" first.' } } BeforeAll { $script:moduleName = '{MyModuleName}' Import-Module -Name $script:moduleName -Force -ErrorAction 'Stop' }
Files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1
CHANGELOG.md
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines-changelog.instructions.md)
CHANGELOG.md: Always update the Unreleased section in CHANGELOG.md
Use Keep a Changelog format in CHANGELOG.md
Describe notable changes briefly in CHANGELOG.md, ≤2 items per change type
Reference issues using format issue #<issue_number> in CHANGELOG.md
No empty lines between list items in same section of CHANGELOG.md
Skip adding entry if same change already exists in Unreleased section of CHANGELOG.md
No duplicate sections or items in Unreleased section of CHANGELOG.mdAlways update CHANGELOG.md Unreleased section
Files:
CHANGELOG.md
⚙️ CodeRabbit configuration file
CHANGELOG.md: # Changelog Guidelines
- Always update the Unreleased section in CHANGELOG.md
- Use Keep a Changelog format
- Describe notable changes briefly, ≤2 items per change type
- Reference issues using format issue #<issue_number>
- No empty lines between list items in same section
- Skip adding entry if same change already exists in Unreleased section
- No duplicate sections or items in Unreleased section
Files:
CHANGELOG.md
**/*.md
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines-markdown.instructions.md)
**/*.md: Wrap lines at word boundaries when over 80 characters (except tables/code blocks)
Use 2 spaces for indentation in Markdown files
Use '1.' for all items in ordered lists (1/1/1 numbering style)
DisableMD013rule by adding a comment for tables/code blocks exceeding 80 characters
Empty lines required before/after code blocks and headings (except before line 1)
Escape backslashes in file paths only (not in code blocks)
Code blocks must specify language identifiers
Format parameters using bold in Markdown documentation
Format values and literals usinginline codein Markdown documentation
Format resource/module/product names using italic in Markdown documentation
Format commands/files/paths usinginline codein Markdown documentation
Files:
CHANGELOG.md
⚙️ CodeRabbit configuration file
**/*.md: # Markdown Style Guidelines
- Wrap lines at word boundaries when over 80 characters (except tables/code blocks)
- Use 2 spaces for indentation
- Use '1.' for all items in ordered lists (1/1/1 numbering style)
- Disable
MD013rule by adding a comment for tables/code blocks exceeding 80 characters- Empty lines required before/after code blocks and headings (except before line 1)
- Escape backslashes in file paths only (not in code blocks)
- Code blocks must specify language identifiers
Text Formatting
- Parameters: bold
- Values/literals:
inline code- Resource/module/product names: italic
- Commands/files/paths:
inline code
Files:
CHANGELOG.md
tests/Unit/Public/*.[Tt]ests.ps1
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines-pester.instructions.md)
Public commands:
tests/Unit/Public/{Name}.Tests.ps1
Files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
tests/[Uu]nit/**/*.[Tt]ests.ps1
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines-unit-tests.instructions.md)
tests/[Uu]nit/**/*.[Tt]ests.ps1: Test with localized strings usingInModuleScope -ScriptBlock { $script:localizedData.Key }
Mock files using the$TestDrivevariable (path to the test drive)
All public commands require parameter set validation tests
Use the exact setup block with BeforeDiscovery, BeforeAll, and AfterAll blocks including DscResource.Test module import and PSDefaultParameterValues configuration
Parameter set validation tests should use Get-Command with Where-Object filtering and Should assertions to verify ParameterSetName and ParameterListAsString
Parameter property tests should verify mandatory parameter attributes using Get-Command Parameters and Should -BeTrue assertions
Files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
⚙️ CodeRabbit configuration file
tests/[Uu]nit/**/*.[Tt]ests.ps1: # Unit Tests Guidelines
- Test with localized strings: Use
InModuleScope -ScriptBlock { $script:localizedData.Key }- Mock files: Use
$TestDrivevariable (path to the test drive)- All public commands require parameter set validation tests
- After modifying classes, always run tests in new session (for changes to take effect)
Test Setup Requirements
Use this exact setup block before
Describe:[System.Diagnostics.CodeAnalysis.SuppressMessageAttribute('PSUseDeclaredVarsMoreThanAssignments', '', Justification = 'Suppressing this rule because Script Analyzer does not understand Pester syntax.')] param () BeforeDiscovery { try { if (-not (Get-Module -Name 'DscResource.Test')) { # Assumes dependencies have been resolved, so if this module is not available, run 'noop' task. if (-not (Get-Module -Name 'DscResource.Test' -ListAvailable)) { # Redirect all streams to $null, except the error stream (stream 2) & "$PSScriptRoot/../../../build.ps1" -Tasks 'noop' 3>&1 4>&1 5>&1 6>&1 > $null } # If the dependencies have not been resolved, this will throw an error. Import-Module -Name 'DscResource.Test' -Force -ErrorAction 'Stop' } } catch [System.IO.FileNotFoundException] { throw 'DscResource.Test module dependency not found. Please run ".\build.ps1 -ResolveDependency -Tasks noop" first.' } } BeforeAll { $script:moduleName = '{MyModuleName}' Import-Module -Name $script:moduleName -Force -ErrorAction 'Stop' $PSDefaultParameterValues['InModuleScope:ModuleName'] = $script:moduleName $PSDefaultParameterValues['Mock:ModuleName'] = $script:moduleName $PSDefaultParameterValues['Should:ModuleName'] = $script:moduleName } AfterAll { $PSDefaultParameterValues.Remove('InModuleScope:ModuleName') $PSDefaultParameterValues.Remove('Mock:ModuleNam...
Files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
tests/Unit/**/*.Tests.ps1
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines.instructions.md)
Unit tests should be located in
tests/Unit/{Classes|Public|Private}/{Name}.Tests.ps1
Files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
source/**/*.ps1
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines-localization.instructions.md)
source/**/*.ps1: Localize all Write-Debug, Write-Verbose, Write-Error, Write-Warning and $PSCmdlet.ThrowTerminatingError() messages in PowerShell scripts
Use localized string keys from $script:localizedData, not hardcoded strings, in diagnostic messages
Reference localized strings using the syntax: Write-Verbose -Message ($script:localizedData.KeyName -f $value1)Localize all strings using string keys; remove any orphaned string keys
Files:
source/Public/New-SqlDscDatabase.ps1
⚙️ CodeRabbit configuration file
source/**/*.ps1: # Localization GuidelinesRequirements
- Localize all Write-Debug, Write-Verbose, Write-Error, Write-Warning and $PSCmdlet.ThrowTerminatingError() messages
- Use localized string keys, not hardcoded strings
- Assume
$script:localizedDatais availableString Files
- Commands/functions:
source/en-US/{MyModuleName}.strings.psd1- Class resources:
source/en-US/{ResourceClassName}.strings.psd1Key Naming Patterns
- Format:
Verb_FunctionName_Action(underscore separators), e.g.Get_Database_ConnectingToDatabaseString Format
ConvertFrom-StringData @' KeyName = Message with {0} placeholder. (PREFIX0001) '@String IDs
- Format:
(PREFIX####)- PREFIX: First letter of each word in class or function name (SqlSetup → SS, Get-SqlDscDatabase → GSDD)
- Number: Sequential from 0001
Usage
Write-Verbose -Message ($script:localizedData.KeyName -f $value1)
Files:
source/Public/New-SqlDscDatabase.ps1
source/Public/*.ps1
📄 CodeRabbit inference engine (.github/instructions/dsc-community-style-guidelines.instructions.md)
Public commands should be located in
source/Public/{CommandName}.ps1
Files:
source/Public/New-SqlDscDatabase.ps1
🧠 Learnings (27)
📚 Learning: 2025-11-27T17:58:02.402Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/SqlServerDsc-guidelines.instructions.md:0-0
Timestamp: 2025-11-27T17:58:02.402Z
Learning: Applies to **/tests/Integration/**/*.ps1 : Integration tests: use `Connect-SqlDscDatabaseEngine` for SQL Server DB session with correct CI credentials, and always follow with `Disconnect-SqlDscDatabaseEngine`
Applied to files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1CHANGELOG.mdtests/Unit/Public/New-SqlDscDatabase.Tests.ps1source/Public/New-SqlDscDatabase.ps1
📚 Learning: 2025-11-27T17:58:02.402Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/SqlServerDsc-guidelines.instructions.md:0-0
Timestamp: 2025-11-27T17:58:02.402Z
Learning: Applies to **/tests/**/*.tests.ps1 : Add `$env:SqlServerDscCI = $true` in `BeforeAll` block and remove in `AfterAll` block of unit tests
Applied to files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
📚 Learning: 2025-11-27T17:59:27.192Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-pester.instructions.md:0-0
Timestamp: 2025-11-27T17:59:27.192Z
Learning: Applies to **/*.[Tt]ests.ps1 : All public commands and class-based resources must have integration tests
Applied to files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1
📚 Learning: 2025-11-27T17:58:31.900Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-integration-tests.instructions.md:0-0
Timestamp: 2025-11-27T17:58:31.900Z
Learning: Applies to tests/Integration/**/*.Integration.Tests.ps1 : Integration tests must cover all scenarios and code paths
Applied to files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1
📚 Learning: 2025-11-27T17:58:02.402Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/SqlServerDsc-guidelines.instructions.md:0-0
Timestamp: 2025-11-27T17:58:02.402Z
Learning: Applies to **/tests/**/*.tests.ps1 : When unit tests test classes or commands containing SMO types like `[Microsoft.SqlServer.Management.Smo.*]`, ensure they are properly stubbed in SMO.cs
Applied to files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
📚 Learning: 2025-11-27T17:58:31.900Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-integration-tests.instructions.md:0-0
Timestamp: 2025-11-27T17:58:31.900Z
Learning: Applies to tests/Integration/**/*.Integration.Tests.ps1 : Call commands with `-Force` parameter where applicable to avoid prompting
Applied to files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1
📚 Learning: 2025-11-27T18:00:35.054Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines.instructions.md:0-0
Timestamp: 2025-11-27T18:00:35.054Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : Integration tests for commands should be located in `tests/Integration/Commands/{CommandName}.Integration.Tests.ps1`
Applied to files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1
📚 Learning: 2025-11-27T17:58:31.900Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-integration-tests.instructions.md:0-0
Timestamp: 2025-11-27T17:58:31.900Z
Learning: Applies to tests/Integration/Commands/*.Integration.Tests.ps1 : Location for Commands integration tests: `tests/Integration/Commands/{CommandName}.Integration.Tests.ps1`
Applied to files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1
📚 Learning: 2025-11-27T18:00:20.925Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-unit-tests.instructions.md:0-0
Timestamp: 2025-11-27T18:00:20.925Z
Learning: Applies to tests/[Uu]nit/**/*.[Tt]ests.ps1 : Parameter property tests should verify mandatory parameter attributes using Get-Command Parameters and Should -BeTrue assertions
Applied to files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
📚 Learning: 2025-11-27T17:58:31.900Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-integration-tests.instructions.md:0-0
Timestamp: 2025-11-27T17:58:31.900Z
Learning: Applies to tests/Integration/**/*.Integration.Tests.ps1 : Integration tests must include the required setup block with BeforeDiscovery that imports DscResource.Test module and BeforeAll that imports the module being tested
Applied to files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1
📚 Learning: 2025-11-27T17:58:31.900Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-integration-tests.instructions.md:0-0
Timestamp: 2025-11-27T17:58:31.900Z
Learning: Applies to tests/Integration/**/*.Integration.Tests.ps1 : Avoid `ExpectedMessage` parameter for `Should -Throw` assertions in integration tests
Applied to files:
tests/Integration/Commands/New-SqlDscDatabase.Integration.Tests.ps1
📚 Learning: 2025-11-27T17:58:02.401Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/SqlServerDsc-guidelines.instructions.md:0-0
Timestamp: 2025-11-27T17:58:02.401Z
Learning: Applies to **/*.ps1 : Format public commands as `{Verb}-SqlDsc{Noun}` following PowerShell naming conventions
Applied to files:
CHANGELOG.md
📚 Learning: 2025-11-27T17:58:02.401Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/SqlServerDsc-guidelines.instructions.md:0-0
Timestamp: 2025-11-27T17:58:02.401Z
Learning: Applies to **/resources/**/*.ps1 : Add `InstanceName`, `ServerName`, and `Credential` to `$this.ExcludeDscProperties` in Database Engine resources
Applied to files:
CHANGELOG.mdtests/Unit/Public/New-SqlDscDatabase.Tests.ps1source/Public/New-SqlDscDatabase.ps1
📚 Learning: 2025-11-27T17:58:02.402Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/SqlServerDsc-guidelines.instructions.md:0-0
Timestamp: 2025-11-27T17:58:02.402Z
Learning: Applies to **/tests/**/*.tests.ps1 : In unit tests: use SMO stub types from SMO.cs, never mock SMO types
Applied to files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
📚 Learning: 2025-08-17T10:13:30.079Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2136
File: source/Public/Remove-SqlDscLogin.ps1:104-108
Timestamp: 2025-08-17T10:13:30.079Z
Learning: In SqlServerDsc unit tests, SMO object stubs (like Login objects) should have properly mocked Parent properties with correct Server stub types and valid InstanceName values, rather than handling null Parent scenarios in production code.
Applied to files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
📚 Learning: 2025-11-27T17:58:02.402Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/SqlServerDsc-guidelines.instructions.md:0-0
Timestamp: 2025-11-27T17:58:02.402Z
Learning: After changing SMO stub types in SMO.cs, run tests in a new PowerShell session for changes to take effect
Applied to files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
📚 Learning: 2025-11-27T17:59:27.192Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-pester.instructions.md:0-0
Timestamp: 2025-11-27T17:59:27.192Z
Learning: Applies to **/*.[Tt]ests.ps1 : Omit `-MockWith` when returning `$null`
Applied to files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
📚 Learning: 2025-11-27T17:59:27.192Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-pester.instructions.md:0-0
Timestamp: 2025-11-27T17:59:27.192Z
Learning: Applies to **/*.[Tt]ests.ps1 : Mock variables prefix: 'mock'
Applied to files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
📚 Learning: 2025-11-27T17:59:27.192Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-pester.instructions.md:0-0
Timestamp: 2025-11-27T17:59:27.192Z
Learning: Applies to **/*.[Tt]ests.ps1 : Never add an empty `-MockWith` block
Applied to files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
📚 Learning: 2025-09-25T16:38:08.867Z
Learnt from: johlju
Repo: dsccommunity/ActiveDirectoryDsc PR: 741
File: tests/Integration/MSFT_ADReadOnlyDomainControllerAccount.Integration.Tests.ps1:102-104
Timestamp: 2025-09-25T16:38:08.867Z
Learning: Test-DscConfiguration cmdlet returns string values 'True' or 'False', not boolean values. Therefore, Should -Be 'True' is correct, and Should -BeTrue would be incorrect for this cmdlet.
Applied to files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
📚 Learning: 2025-11-27T18:00:20.925Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-unit-tests.instructions.md:0-0
Timestamp: 2025-11-27T18:00:20.925Z
Learning: Applies to tests/[Uu]nit/**/*.[Tt]ests.ps1 : Parameter set validation tests should use Get-Command with Where-Object filtering and Should assertions to verify ParameterSetName and ParameterListAsString
Applied to files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
📚 Learning: 2025-08-16T13:22:15.230Z
Learnt from: johlju
Repo: dsccommunity/SqlServerDsc PR: 2134
File: tests/Unit/Public/Get-SqlDscLogin.Tests.ps1:78-93
Timestamp: 2025-08-16T13:22:15.230Z
Learning: In PowerShell unit tests for parameter validation in SqlServerDsc, accessing parameter attributes directly like `$cmd.Parameters['ParameterName'].Attributes.Mandatory` works correctly because PowerShell automatically iterates through the array and returns the property values. Additional filtering to ParameterAttribute is not necessary when the parameter structure is known and controlled.
Applied to files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
📚 Learning: 2025-11-27T17:59:01.498Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-mof-resources.instructions.md:0-0
Timestamp: 2025-11-27T17:59:01.498Z
Learning: Applies to source/DSCResources/**/*.psm1 : `Set-TargetResource` and `Test-TargetResource` must have identical parameters
Applied to files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
📚 Learning: 2025-11-27T18:00:20.925Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-unit-tests.instructions.md:0-0
Timestamp: 2025-11-27T18:00:20.925Z
Learning: Applies to tests/[Uu]nit/**/*.[Tt]ests.ps1 : All public commands require parameter set validation tests
Applied to files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
📚 Learning: 2025-11-27T17:59:01.498Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-mof-resources.instructions.md:0-0
Timestamp: 2025-11-27T17:59:01.498Z
Learning: Applies to source/DSCResources/**/*.psm1 : Unused mandatory parameters in `Set-TargetResource` and `Test-TargetResource` should include "Not used in <function_name>" in the help comment
Applied to files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
📚 Learning: 2025-11-27T17:59:01.498Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-mof-resources.instructions.md:0-0
Timestamp: 2025-11-27T17:59:01.498Z
Learning: Applies to source/DSCResources/**/*.psm1 : `Get-TargetResource` should only include parameters needed to retrieve actual current state values
Applied to files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
📚 Learning: 2025-11-27T18:00:11.915Z
Learnt from: CR
Repo: dsccommunity/SqlServerDsc PR: 0
File: .github/instructions/dsc-community-style-guidelines-powershell.instructions.md:0-0
Timestamp: 2025-11-27T18:00:11.915Z
Learning: Applies to **/*.{ps1,psm1,psd1} : Parameters should use full type name
Applied to files:
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: dsccommunity.SqlServerDsc (Build Package Module)
- GitHub Check: PSScriptAnalyzer
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2356 +/- ##
=====================================
- Coverage 94% 94% -1%
=====================================
Files 164 164
Lines 9563 9709 +146
=====================================
+ Hits 9070 9152 +82
- Misses 493 557 +64
🚀 New features to boost your workflow:
|
…rver version requirements
…y SQL Server version requirements
…n properties in New-SqlDscDatabase and Set-SqlDscDatabaseProperty
…se SwitchParameter for better PowerShell practices and update related tests for default values.
…ameter for boolean properties and enhance related tests for consistency and clarity.
…an properties and update related tests for consistency
…DatabaseProperty tests to use colon syntax for boolean properties
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
source/Public/Set-SqlDscDatabaseProperty.ps1 (1)
575-578: StandardizeMaxSizeInBytestype with New-/Test- commands
MaxSizeInBytesis typed as[System.Double]here, while the corresponding parameter inTest-SqlDscDatabasePropertyis[System.Int64]. For a size-in-bytes value this discrepancy is surprising and may lead to precision issues and a confusing API surface across the three commands. Consider aligning this to an integer type consistent with both SMO and the Test cmdlet, similar to the suggestion onNew-SqlDscDatabase.Confirm the .NET type of `Microsoft.SqlServer.Management.Smo.Database.MaxSizeInBytes` and ensure Set-/New-/Test-SqlDscDatabaseProperty all use the same parameter type for this property.
🧹 Nitpick comments (3)
tests/Integration/Commands/Test-SqlDscDatabaseProperty.Integration.Tests.ps1 (1)
90-92: Reclassifying these properties to the non-Boolean test path looks correctBy dropping
TestValueonParameterSniffing,LegacyCardinalityEstimation,QueryOptimizerHotfixes, andDelayedDurability, these cases no longer participate in the boolean$true/$falseloop (Where-Object { $_.TestValue }) and instead are exercised by the non-Boolean tests (Where-Object { -not $_.TestValue }), which pass the actual SMO value (including enums) through toTest-SqlDscDatabaseProperty. This matches the intent if these parameters are now enum/DB-scoped configuration style rather than simple booleans, and I don’t see a functional problem.As a small clarity tweak, you might consider moving these four entries out from under the “Boolean properties” comment or adding a note that they are logically toggle-like but tested via the non-Boolean path now.
Also applies to: 101-101
tests/Unit/Public/New-SqlDscDatabase.Tests.ps1 (1)
221-265: Parameter validation uses sample-based approach.The parameter validation tests check for the existence of core parameters and sample parameters from each property type category. This approach validates the pattern but may not catch if individual parameters are accidentally omitted.
If more comprehensive validation is desired, consider checking all expected parameters rather than just samples. However, the current sample-based approach is acceptable for validating that the parameter set structure is correct and parameters of each type are present.
source/Public/Test-SqlDscDatabaseProperty.ps1 (1)
462-464: Update.PARAMETER UserAccesshelp text to use actual enum member namesThe
.PARAMETER UserAccesshelp referencesMULTI_USER,RESTRICTED_USER,SINGLE_USER, but the parameter acceptsMicrosoft.SqlServer.Management.Smo.DatabaseUserAccessenum which has members:Multiple,Single, andRestricted. Update the help text to use the actual enum member names to prevent confusion and binding surprises.
…lDscDatabaseProperty
johlju
left a comment
johlju
left a comment
There was a problem hiding this comment.
@johlju reviewed 8 of 11 files at r2, 3 of 3 files at r3, 1 of 1 files at r4, all commit messages.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on @johlju)
2 participants
Pull Request (PR) description
New-SqlDscDatabaseonly available in `Set-SqlDscDatabaseProperty
(issue #2190).
This Pull Request (PR) fixes the following issues
New-SqlDscDatabase: Add missing settable properties #2190Task list
file CHANGELOG.md. Entry should say what was changed and how that
affects users (if applicable), and reference the issue being resolved
(if applicable).
This change is