The Equals validation rule is case insensitive when comparing string values

[icnocop]

Hi.

The description of the Equals validation rule on https://github.com/dpiessens/specbind/wiki/Verifying-Steps indicates

The expected value and actual value are an exact match.

So I expected that a comparison of the string values test and Test to fail.

The unexpected behavior also exists in the NotEquals, StartsWith, and EndsWith comparers.

This is inconsistent with the Contains and DoesNotContain comparers which are case sensitive.

One solution could be to create new validation rules to differentiate between the case sensitivity comparison.
For example:

Rule	Case
Equals	Sensitive
Equivalent	Insensitive
Not Equal	Sensitive
Not Equivalent	Insensitive
Starts With	Sensitive
Starts With Equivalent	Insensitive
Ends With	Sensitive
Ends With Equivalent	Insensitive
Contains	Sensitive
Contains Equivalent	Insensitive
Does Not Contain	Sensitive
Does Not Contain Equivalent	Insensitive

Another option is to create a SpecBind configuration setting that defines the sensitivity option during string comparisons.

It seems the only benefit of having the additional validation rules is the flexibility when comparing strings in multiple scenarios with mixed sensitivity within the same project.

I prefer string comparisons to be case sensitive by default.
I expect the Equals, NotEquals, StartsWith, and EndsWith comparers to be case sensitive.
I don't and I'm not sure who else has a need for case insensitive comparisons at the moment, so maybe we don't have to implement the Equivalent comparers (yet?).

Thank you.

[NickMcG]

What about adding an optional column to the validation table? If you don't add the extra value to the validation row, then it defaults to case insensitive; otherwise, you can specify whether it is case sensitive?

[icnocop]

@NickMcG, yes, that is another option. :)

The only "drawback" with that approach is the column doesn't apply for all the rules like Less Than*, Greater Than*, Exists, Does Not Exist, *Enabled and Disabled.

I would also consider the definition of "equals" to be "==" which is case sensitive for string comparisons by default in .NET and JavaScript for example.

[dpiessens]

The fact that Contains and DoesNotContain are different are limitations of the .NET framework. There's no case insensitive comparison for it unfortunately.

Everything else is case-insensitive as most of the feedback I've received from people over the years is they don't want to be tangled up by someone changing the case of a letter. I can update the documentation to reflect that these comparisons are case insensitive.

What's your use case for needing case sensitivity?

[icnocop]

My specific use case is when dealing with abbreviations for file sizes.

For example, b is bit while B is byte.

Another use case is related to file names which in Windows 10 build 17093 (April 2018 Update) can now be made case sensitive.
For reference, https://docs.microsoft.com/en-us/windows/wsl/release-notes#build-17093

Here is some code with a case insensitive contains method implementation.
https://dotnetthoughts.net/how-to-make-string-contains-case-insensitive/

Thank you.

[icnocop]

FWIW, the element selector in [ElementLocator(Id = "MyElementIdentifier")] is case sensitive, at least when using Selenium.