Closed dfch closed 9 years ago
The Should Be
assertion uses -eq
operator internally and inherits all it's behavior including everything that might seem like a quirk. PowerShell (and it's users) usually do not care about the types much, and there are well defined rules to which the operators (and hence the assertions) comply. So the assertions work as designed.
Your examples of "false positive" and "false negative" show what I would expect to see: comparing string 3
to integer 3
results in them being equal.
In the rest of your examples you use ScriptBlocks to specify the type, but you use it incorrectly and what is actually happening is that instead of integer 3
you get back string [int] 3
as in this example:
3 -eq "[int] 3"
which is false. To correct the code you'd have to call it as such:
([string] '3') -eq ([int] 3); #use () instead of {}
But that again results in true.
Do you have a real life use case where you need to differentiate between the two types of comparison?
Maybe #327 might help you?
Hi @nohwnd thanks for the clarification on the implementation and correct usage of the script block.
I had the use case when encapsulating a third party REST API where the return data came back as JSON which we processed and returned. There it made sense to return correct data types and properly check for them (in the end this is what unit tests are made for in my opinion).
At least for BeExactly
I would have expected an exact comparison, otherwise it is a little bit misleading and BeCaseSensitive
(or something else) might be more appropriate.
And yes, you are probably right, that not all PowerShell users might be too interested in this. However, all the testing frameworks I used before always supported this (maybe that's why I am caring about this at all).
But if you think this is not adding a value to the framework, feel free to close the issue. Regards, Ronald
It would, of course, be a total disaster to change this behavior now.
When using
should
to assert values, the data type is not checked leading to false test results.False Negative
False Positive
In addition, these test fail, though they should actually succeed:
Correct comparison
Only when you specifically supply the type, the comparison is done correctly (i.e. the tests fail):
In my opinion the behaviour should be similar to the behaviour of the
[Microsoft.VisualStudio.TestTools.UnitTesting.Assert]
class where you have specificAreEqual
methods that also compare the given data type: