Open cparker4486 opened 8 years ago
@cparker4486 I agree that the AddNumber
example doesn't really help explain the benefits of using the framework. A better example should be provided.
The main benefit of using OVF with Pester tests for your infrastructure is that by bundling your tests into a module, you gain the benefit of having a versionable and publishable package that you can deploy to your infrastructure or share with others using the PowerShell Gallery for example.
Perhaps a better example they could give is actually testing a server for running services or listening ports this below:
describe 'MyApp' {
context 'Availability' {
it 'MyApp service is running' {
$s = Get-Service -Name 'MyAppService' -ErrorAction SilentlyContinue
$s.Status | should be 'running'
}
it 'Port 8080 is listening' {
(Test-NetConnection -Port 8080 -ComputerName localhost).TcpTestSucceeded | should be $true
}
}
}
When you combine this framework with things like poshspec (provides some nice helper functions that creating Pester tests for your infrastructure), I think you'll start to see the power in using these tools.
You can look at these modules I'm working on as examples for how I see this framework being used. These modules are published to the PowerShell Gallery.
@devblackops
Thanks for the great information and links. This makes a lot more sense now.
As far as this issue goes. What do I do? I have my question answered but the base issue of the example needing improvement still remains.
Coming back to this again and I noticed another problem. The commands provided by the module are Get-OperationValidation
and Invoke-OperationValidation
. Then the example file shows get-operationtest
and invoke-operationtest
.
thanks for catching the error in the examples, that change has been committed.
It was a little hard when I was trying to create examples. All of the interesting examples would require some service or another which I couldn't really rely on. I suppose I could mock these, but it didn't occur to me at the time. Also, I was more focused on making sure that folks understood how tests were being run rather than the specifics of the test.
I can certainly add something, but it would be mocked, (not retrieving real world data), would that be ok?
@JamesWTruher If I understand you, I think a mock example is appropriate.
Hello!
I'm a novice when it comes to this stuff so let me get that out of the way up front.
I understand the concept of testing code. I understand how Pester achieves that for PowerShell. I understand what a PowerShell Module is (admittedly I might not understand the full scope of modules). I think I understand what OVF is supposed to do. What I don't understand is why the example is the way it is.
In the example there's a module called AddNumbers. Yet, the Pester tests created to run against that module are things like firewall rules for TCP ports. I don't see how those have anything to do with each other.
If I wanted to validate the operation of my network (e.g. check that a service on my Exchange server was running) what kind of module would I be making? I feel like I would just skip straight to the Pester tests and run those. What kind of function would be in a module that I would write a Pester test against to achieve my goal of validating the operation of Exchange?
Perhaps a better example would be a module that was actually related to testing TCP ports and not adding numbers??