Enhance Set-ItResult to add more options
1. General summary of the issue
I need to be able to set more than the default kinds of ItResults.
2. Describe Your Environment
Operating System, Pester version, and PowerShell version:
Pester version : 4.8.1 C:\Program Files\WindowsPowerShell\Modules\Pester\4.8.1\Pester.psd1 PowerShell version : 5.1.14409.1005 OS version : Microsoft Windows NT 6.3.9600.0
3. Expected Behavior
As a user, I want Set-ItResult to also include other states so that the NUnit xml file will have all of the states possible when using tools like http://extentreports.com/.
- Include -Fatal
- Include -Error
4.Current Behavior
It Results are currently Success, Fail, Warning, Skip
5. Possible Solution
add 2 more states into the next release.
6. Context
depending on the error, it is nice to have more than just warning and fail
Thanks for the issue. I am a bit confused about what are the states you desire. Are those Error and Fatal? How is Error different from Failed? What would Fatal mean and in which situations it should be used?
Thanks for the issue. I am a bit confused about what are the states you desire. Are those Error and Fatal? How is Error different from Failed? What would Fatal mean and in which situations it should be used?
Here is my use case: I am running pester on a windows system doing an 800+ point check up, some things need to fail when | Should -be X is not X, but some things i cannot access or there is a different level of error that i need access to. So, lets say values that should be something stay in fail, but lets say i am unable to access SQL to run my tests, that would be an Error. Or lets say windows needs to be reboot and it is causing an instability in the system, that should be a Fatal.
Does this help? Having Fail lvl 1, Fail lvl 2, Fail lvl 3, would help address the level of impact to the system more accurately.
Also being able to set the Should fail state to something at the should area would be way better. "Bob" | Should -Be "Smith" -Because "it should be this way" -ItResult Failed "Bob" | Should -Be "Smith" -Because "it should be this way" -ItResult Skipped "Bob" | Should -Be "Smith" -Because "it should be this way" -ItResult Inconclusive (aka Warning) "Bob" | Should -Be "Smith" -Because "it should be this way" -ItResult Fatal "Bob" | Should -Be "Smith" -Because "it should be this way" -ItResult Error "Bob" | Should -Be "Smith" -Because "it should be this way" -ItResult Pending
Here are some examples:
- When access to SQL fail this is Error from a try catch.
- When the SQL service is down this is Fatal.
- When windows needs to reboot, this is Inconclusive.
- When i cannot ping x ip, this is Fatal.
- When the value in sql is wrong, this is Failed
- When the value in sql is right, this is success
- When writing only the tests and the values are unknown, this is Pending because we are developing the test.
- When x program is not installed, then all these tests are skipped.
Here is a picture of the Extent Dashboard: http://extentreports.com/img/bdd/dashboard.png
I found what they consider each group as:
switch (str)
{
case "skipped":
case "ignored":
case "not-run":
case "notrun":
case "notexecuted":
case "not-executed":
return Status.Skip;
case "pass":
case "passed":
case "success":
return Status.Pass;
case "warning":
case "bad":
case "pending":
case "inconclusive":
case "notrunnable":
case "disconnected":
case "passedbutrunaborted":
return Status.Warning;
case "fail":
case "failed":
case "failure":
case "invalid":
return Status.Fail;
case "error":
case "aborted":
case "timeout":
return Status.Error;
default:
//return Status.Unknown;
return Status.Debug;
}
NUnit3 schema supports:
- Inconclusive
- Skipped
- Passed
- Warning (in schema, not in docs)
- Failed