Allow specifying EquivalencyOptions in string assertions

[vbreuss]

Enhance the EquivalencyOptions to support the following methods:

• IgnoringLeadingWhitespace
  Instructs the comparison to ignore leading whitespace when comparing strings.
• IgnoringTrailingWhitespace
  Instructs the comparison to ignore trailing whitespace when comparing strings.
• IgnoringCase
  Instructs the comparison to compare strings case-insensitive.

Add an overload for the following string assertions that accept a Func<EquivalencyOptions<string>, EquivalencyOptions<string>> config.

• BeEquivalentTo
• ContainEquivalentOf
• EndWithEquivalentOf
• MatchEquivalentOf
• NotBeEquivalentTo
• NotContainEquivalentOf
• NotEndWithEquivalentOf
• NotMatchEquivalentOf
• NotStartWithEquivalentOf
• StartWithEquivalentOf

Details are discussed in and fixes #2364.
Fixes #2339
Fixes #2064

IMPORTANT

• If the PR touches the public API, the changes have been approved in a separate issue with the "api-approved" label.
• The code complies with the Coding Guidelines for C#.
• The changes are covered by unit tests which follow the Arrange-Act-Assert syntax and the naming conventions such as is used in these tests.
• If the PR adds a feature or fixes a bug, please update the release notes with a functional description that explains what the change means to consumers of this library, which are published on the website.
• If the PR changes the public API the changes needs to be included by running AcceptApiChanges.ps1 or AcceptApiChanges.sh.
• If the PR affects the documentation, please include your changes in this pull request so the documentation will appear on the website.
  • Please also run ./build.sh --target spellcheck or .\build.ps1 --target spellcheck before pushing and check the good outcome

[vbreuss]

If this pull request is accepted, it replaces #2372

[coveralls]

Pull Request Test Coverage Report for Build 7436672942

Warning: This coverage report may be inaccurate.

We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
To ensure accuracy in future PRs, please see these guidelines.
A quick fix for this PR: rebase it; your next report should be accurate.

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.02%) to 97.45%

---

Totals
Change from base Build 7378622478:	-0.02%
Covered Lines:	11943
Relevant Lines:	12130

---

💛 - Coveralls

[vbreuss]

@dennisdoomen :
I don't understand why the Qodana Scan fails. Is it a problem with the pipeline or with the code changes? Can I see somewhere, what the actual failures are (the raw build log is not really helpful for me)?

[dennisdoomen]

I don't understand why the Qodana Scan fails. Is it a problem with the pipeline or with the code changes? Can I see somewhare, what the actual failures are (the raw build log is not really helpful for me)?

Is that because you're branch is behind and needs to rebase?

[vbreuss]

Is that because you're branch is behind and needs to rebase?

I doubt it, as the build ran and the failure was before the merge of #2416 to develop.
Nonetheless I rebased the branch to get rid of the conflicting files.

[dennisdoomen]

That's a pretty impressive PR. It just needs a little cleaning up here and there.

[dennisdoomen]

Nice work

[IT-VBFK]

@vbreuss Can you try behavior instead of behaviour in string.md and check if that silence the spell check?
And if so, probably you could add the british version to the custom dict. ;)

[vbreuss]

@vbreuss Can you try behavior instead of behaviour in string.md and check if that silence the spell check? And if so, probably you could add the british version to the custom dict. ;)

Yes, changing it to behavior does indeed fix the spell check error.

Sorry, I was not aware, that I need to run it locally! 😃

@IT-VBFK : Where can I find the custom dictionary?

[IT-VBFK]

in the repository root cSpell.json -> words :)

[dennisdoomen]

And if so, probably you could add the british version to the custom dict. ;)

It's not completely obvious, but we're using US English as our standard.

[ITaluone]

I think the PR title is litte outdated? Should this go to "Allow specifying EquivalencyOptions in string assertions" instead?

[vbreuss]

I also requeued the build so that wasn't necessary. Our builds build the (virtual) result of merging your PR into the target branch.

@dennisdoomen :
I saw that you manually triggered the Qodana build, but it failed again, so it seems the automatic GitHub merge was incorrect or incomplete. After the manual merge, the build was fine...

Either way, we never merge develop or master in our feature branches. We always use rebases.

I was not aware of this guideline. The build is now also successful after a rebase 😄
Maybe we could add this information to the DOs and DON'Ts?

[jnyrup]

Just two small things.
very impressive work ❤️

[bart-vmware]

I don't understand how the linked PR that closes this issue solves my problem. It doesn't fix the next bug, which I pointed out earlier:

public static string RemoveNewLines(this string @this)
{
    return @this.Replace("\n", string.Empty, StringComparison.Ordinal)
        .Replace("\r", string.Empty, StringComparison.Ordinal)
        .Replace(@"\r\n", string.Empty, StringComparison.Ordinal);
}

Note the @ verbatim string modifier, which is equivalent to matching "\\r\\n" instead of "\r\n".

Aside from that, how do these changes affect my use case? In other words, what FA extension method should I be using now to pass my custom string comparer (without also ignoring leading/trailing whitespace, line breaks, casing, etc)?

[vbreuss]

@bart-vmware :
You can now specify the IEqualityComparer<string> that should be used, e.g. with the mentioned IgnoreLineEndingsComparer in #2339:

subject.Should().BeEquivalentTo(expected, o => o
    .Using(IgnoreLineEndingsComparer.Instance));

I don't understand how the linked PR that closes this issue solves my problem. It doesn't fix the next bug, which I pointed out earlier

Or do you mean another issue?

[bart-vmware]

@vbreuss Thanks, but that doesn't actually work. Tracked at #2566.