search

nohwnd / Assert

A set of advanced assertions for Pester to simplify how you write tests.
MIT License
101 stars 12 forks source link

Deserialize DBNull, StrictType and Tests #34

Closed ili101 closed 5 years ago

ili101 commented 6 years ago

Hi

  1. In my previous pull https://github.com/nohwnd/Assert/pull/33 I added support for Deserialized DataTable and DataRow but I missed that there are also deserialized DBNull so I added support for it too.
  2. Added optional parameter Assert-Equivalent -StrictType to give the option to enforce that the data types are the same (for example Assert-Equivalent -Expected 5 -Actual '5' -StrictType will return an error)
  3. Added test for 1 and 2.
  4. Improved tests added in https://github.com/nohwnd/Assert/pull/33 and made them more readable.

Usage example https://github.com/ili101/Join-Object/blob/e46a691c1885815706af65b9f741339d992c8a1c/Tests/Join-Object.Tests.ps1#L344 (allow me to verify that my function returned the numbers as Ints and not Strings)

nohwnd commented 5 years ago

@ili101 Thanks for the PR, I just wanted to let you know that I saw it and plan to merge it at some point, I just need to test it a bit and discuss with myself the if the parametrazition is good as it is. 🙂

ili101 commented 5 years ago

Thank you, For now, I'm just polling the new code directly from my Fork in the AppVeyor test with https://github.com/ili101/Join-Object/blob/Alpha/Tests/Assert.ps1 So no rush.

So far it works very nicely even with nested and mixed Arrays and DataTables, very helpful, thank you for this module :thumbsup:

ili101 commented 5 years ago

Hi @nohwnd, I see that you added Get-EquivalencyOption. Do you want to move the switches -StrictType and -StrictOrder to there? If so what Switches names do you prefer? I don't understand what $options = Get-EquivalencyOption -Comparator Equality suppose to do and I don't see any documentation on how to use it? Is it supposed to be like -StrictType? If so it doesn't really work:

Assert-Equivalent -Actual "False" -Expected $false # Pass
Assert-Equivalent -Actual "False" -Expected $false -Options $options # Fails
Assert-Equivalent -Actual $false -Expected "False" # Pass
Assert-Equivalent -Actual $false -Expected "False" -Options $options # Pass (Supposed to fail as I understend?)
Assert-Equivalent -Actual 5 -Expected "5" # Pass
Assert-Equivalent -Actual 5 -Expected "5" -Options $options # Pass (should fail?)

Also, I'm curious what is the benefit of adding Get-EquivalencyOption instead of regular Params on Assert-Equivalent? I saw this technic on sets of CommandLets that share the same parameters or CommandLets that have distinct segments of parameters like Register-ScheduledTask but I don't see benefit here.

nohwnd commented 5 years ago

I will move the switches somewhere, but at the moment the datatable related stuff is a bit behind, I did not add the verbose stuff or the equality option or more tests will do that when I have some time to work on it again :) As for splitting the options to a different cmdlet I did that originally to allow for easier development, and possible having multiole cmdlets for generating the options, but it turned out to not be worth it and I plan to add the switches on assert-equivalent. I might keep the cmdlet for getting options separate as well because it would allow sharing options between assertion calls easier (by getting the object and splatting). The equality option is meant to make recursive equality check (removing all the fixes I do for equivalency, like comparing booleans differently). It’s all work in progress now