Closed rismoney closed 6 years ago
Thank you for your comment.
I'm not sure if do I understand you. But before I ask questions please check the version 4.1.0 - we released it yesterday.
@rismoney Thanks for the feedback. At the moment I am writing a set of assertion that, among other things, are making the formatting better. I plan to later merge with Pester, most likely starting from the formatting, so I would value your help. The project can be found here and is available on PsGallery. The Assert-Equal
does not properly with collections in the current 0.8.0 version but you might get a feeling of what the formatting does when comparing with null:
$foo = ([pscustomobject]@{ Name='Jakub'; Age=29}),
(ps idle),
{ "sb" },
@{ Pester = "rocks!" },
"item2"
$foo | Assert-Null
Expected $null, but got collection 'PSObject{Age=29; Name=Jakub}, Diagnostics.Process{Id=0; Name=Idle}, { "sb" }, @{Pester=rocks!}, item2'.
At C:\Program Files\WindowsPowerShell\Modules\Assert\0.8.0\src\General\Assert-Null.ps1:12 char:9
+ throw [Assertions.AssertionException]$Message
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [], AssertionException
+ FullyQualifiedErrorId : Expected $null, but got collection 'PSObject{Age=29; Name=Jakub}, Diagnostics.Process{Id=0; Name=Idle}, { "sb" }, @{Pester=rocks!}, item2'.
As for Pester itself I would accept a PR if you post one, but formatting the objects consistently is a difficult process.
This is great @nohwnd - I initially monkey patched some of the asserts and was going to attempt a PR just to see what would be involved to try to massage the formatting and came away with a similar finding that the formatting of the objects consistently became non trivial. I walked away initially and posted because the only way to do it is, as you have found too is TDD because of all the use cases.
I was doing a whole bunch of asserts around nested structures (huge arrays of hashes of arrays) and things got illegible with the current approach.
Let me have a look and see how i can help!
@rismoney will be fixed soon by #996 to print
Expected $null or <empty>, but got @('item1', 'item2').
At C:\projects\pester_nohwnd\Functions\Assertions\Should.ps1:206 char:9
+ throw ( New-ShouldErrorRecord -Message $testResult.FailureMes ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidResult: (System.Collections.Hashtable:Hashtable) [], Exception
+ FullyQualifiedErrorId : PesterAssertionFailed
version 4.08
Issues across the assertion files.
The result comes back:
Expected: value to be empty but it was: {item1 item2}
Ideally the formatting of the $actualvalue should be @(item1,item2) or some other nomenclature. The former conveys a mismatched type. Types and their handling should be consistent through all the assertions. I think with arrays the output is being splatted where it is as though the array actually gets stringified.
Optionally I think items should display as [regex]::Escape($actualvalue) to see line-feeds and other "gotchas" often required in exact matching, or some option flag to support this.
Lastly the $actualvalue may have different formatting requirements, and perhaps these can be customizable somehow? ie table form w/ autosizing?