String Comparison in

[jschpp]

Describe "Koan Bug, Issue, or Help Request"

As discussed here https://twitter.com/vexx32/status/1222174375761281024 there is a small problem with the AboutComparison Koan concerning -lt and -gt in arrays.

Context "The Problematic Assertions"

Specifically in lines 104-107:

PSKoans/PSKoans/Koans/Foundations/AboutComparison.Koans.ps1

Lines 104 to 107 in c450201

	$Array = '1', '5', '10', '15', '20', '25', '30'
	__ | Should -Be ($Array -gt 25)
	@('__', '__') | Should -Be ($Array -lt 10)

Context "Your Attempts"

Trying to instruct a few coworkers in powershell this section caused confusion. From the way the Assertions were laid out it looks as if

__ | Should -Be ($Array -gt 25)

should return a single value and

@('__', '__') | Should -Be ($Array -lt 10)

should return multiple.

Discussing this with @vexx32 on twitter yielded that this string comparison was not intended to be different to an integers comparison in this way.

Either the Array should be numbers only or the Assertions should look like this:

__ | Should -Be ($Array -lt 10)
@('__', '__') | Should -Be ($Array -gt 25)

Context "Additional Information"

I get that a new powershell user should be informed about the way -gt , -lt, -le, -ge interact with strings by sorting them but maybe that should be in a section of it's own :-)

[vexx32]

Yeah, we can simplify that one. I imagine the reason it was originally written that way is because we wanted to have a blank value for users to input into it, but ultimately that didn't end up happening or was later removed. This should probably just be numbers; I think the string sorting behaviour is explained elsewhere, no need to confuse users on this one! 😁

I'll mark it up for grabs in case anyone wants to PR it before I can get around to sorting it. 🙂

[jschpp]

Since you merged the PR #356 I think this can be closed :-)

[vexx32]

@jschpp good catch! 🙂

If you submit a PR again in future, you can add what Github calls "closing keywords" to the PR description, e.g., Closes #356 or Resolves #356 (among a few other forms they support) to automatically close the related issue when the PR is merged. 😊