Pester icon indicating copy to clipboard operation
Pester copied to clipboard

Enhance Set-ItResult to add more options

Open Omzig opened this issue 6 years ago • 4 comments

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

Omzig avatar Aug 22 '19 18:08 Omzig

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?

nohwnd avatar Aug 26 '19 06:08 nohwnd

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

Omzig avatar Aug 27 '19 14:08 Omzig

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;
           }

Omzig avatar Aug 29 '19 15:08 Omzig

NUnit3 schema supports:

  • Inconclusive
  • Skipped
  • Passed
  • Warning (in schema, not in docs)
  • Failed

fflaten avatar Jul 16 '22 17:07 fflaten