-
Notifications
You must be signed in to change notification settings - Fork 10
Testing
To ensure that the code is functioning correctly, following good practices and continues to have backward comatibility, there is a directory of tests.
They all use Pester to run all of the tests, and can be run with the command:
Invoke-Pester -Path .\Tests
You can also run a specific test file, for example:
Invoke-Pester -Path tests\Unit\Get-FabricWorkspaceUser.Tests.ps1
The tests are organized into different files based on the functionality they are testing.
These tests are designed to test individual functions in isolation, ensuring that each function behaves as expected. They do not require any external dependencies or resources.
These tests ensure that the functions continue to work as expected with previous versions of the code. They are particularly important when making changes to existing functions to ensure that no breaking changes are introduced.
for example, the Get-FabricWorkspaceUser
function has the following test:
Context "Alias validation" {
$testCases = @('Get-FabWorkspaceUsers', 'Get-FabricWorkspaceUsers')
It "Should have the alias <_>" -TestCases $TestCases {
$Alias = Get-Alias -Name $_ -ErrorAction SilentlyContinue
$Alias | Should -Not -BeNullOrEmpty
$Alias.ResolvedCommand.Name | Should -Be 'Get-FabricWorkspaceUser'
}
to ensure that the aliases continue to work in the same way as before.
Sometimes functions need to call other functions, and in order to test them in isolation, we can mock those functions. This allows us to control the output of the mocked function and test how the function under test behaves with that output.
For example, the Get-FabricWorkspaceUser
function calls Confirm-TokenState
,Get-FabricWorkspace
and and , so we can mock those functions to return a specific value and test how
Get-FabricWorkspaceUserbehaves in isolation. As
Confirm-TokenState` is a private function we also have to declare in the rest file.
We then define the output that we need from the mocked functions, so that the function under test can use them as if they were the real functions.
BeforeEach {
function Confirm-TokenState {}
Mock Confirm-TokenState {}
Mock Get-FabricWorkspace {
return @(
@{
displayName = 'prod-workspace'
# until the guid datatype is added
Id = [guid]::NewGuid().Guid.ToString()
}, @{
displayName = "test-workspace"
# until the guid datatype is added
Id = [guid]::NewGuid().Guid.ToString()
}
)
}
Mock Invoke-FabricRestMethod {
return @{
value = @(
@{
emailAddress = '[email protected]'
groupUserAccessRight = 'Admin'
displayName = 'Fabric'
identifier = '[email protected]'
principalType = 'User'
}, @{
emailAddress = '[email protected]'
groupUserAccessRight = 'Viewer'
displayName = 'Fabric viewer'
identifier = '[email protected]'
principalType = 'User'
}
)
}
}
}
Once that has been done, we can then test. In the Get-FabricWorkspaceUser
tests for example, we validate that the function will perform as expected for multiple workspaces passed down the pipeline and provided to the Workspace parameter.
It "Should return users for multiple workspaces passed to the Workspace parameter" {
{Get-FabricWorkspaceUser -Workspace (Get-FabricWorkspace) }| Should -Not -BeNullOrEmpty
}
It "Should return users for multiple workspaces passed to the Workspace parameter from the pipeline" {
{ Get-FabricWorkspace | Get-FabricWorkspaceUser
} | Should -Not -BeNullOrEmpty
}