return @{ Field0=1; Field1='ABC'; Field2='03/01/2016' }
}I personally prefer to have separate test suites that test at varying levels of the stack. So I might put all my “unit” tests under a “tests/unit” folder and those will never touch the db. Then I’d have “tests/functional” or “tests/integration” that contain tests the will test against a real db.
Sent from Mail for Windows 10
--
You received this message because you are subscribed to the Google Groups "Pester" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pester+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
+
Project X
+
Functions- Get-Bar.ps1
- Get-Foo.ps1
+ Tests+ Integration
- Get-Bar.Tests.ps1
- Get-Foo.Tests.ps1
How did you adjust the 'dot sourcing' logic of each test file to account for the non-standard directory structure?+ Unit
- Get-Bar.Tests.ps1
- Get-Foo.Tests.ps1
I tend to use psake (https://github.com/psake/psake) as a way to organize build and test tasks so I’d have something like:
Task {
pushd "$baseDir"
$pesterDir = "$env:ChocolateyInstall\lib\Pester"
if($testName){
exec {."$pesterDir\tools\bin\Pester.bat" $baseDir/Tests -testName $testName}
}
else{
exec {."$pesterDir\tools\bin\Pester.bat" $baseDir/Tests }
}
popd
}
Task Integration-Test -depends Pack-Nuget, Create-ModuleZipForRemoting {
pushd "$baseDir"
$pesterDir = "$env:ChocolateyInstall\lib\Pester"
if($testName){
exec {."$pesterDir\tools\bin\Pester.bat" $baseDir/IntegrationTests -testName $testName}
}
else{
exec {."$pesterDir\tools\bin\Pester.bat" $baseDir/IntegrationTests }
}
popd