Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

containExactlyInAnyOrder does not handle custom verifier properly #3840

Open
AlexCue987 opened this issue Jan 19, 2024 · 5 comments · May be fixed by #3976
Open

containExactlyInAnyOrder does not handle custom verifier properly #3840

AlexCue987 opened this issue Jan 19, 2024 · 5 comments · May be fixed by #3976
Labels
assertions 🔍 Related to the assertion mechanisms within the testing framework. bug 🐛 Issues that report a problem or error in the code. question ❓ Inquiries or clarifications needed about the project.

Comments

@AlexCue987
Copy link
Contributor

AlexCue987 commented Jan 19, 2024

latest code from master
the following code shows the issue. these two lists should match wrt this verifier, but they don't:

            val caseInsensitiveStringEquality: Equality<String> = object : Equality<String> {
               override fun name() = "Case Insensitive String Matcher"

               override fun verify(actual: String, expected: String): EqualityResult {
                  return if(actual.uppercase() == expected.uppercase())
                     EqualityResult.equal(actual, expected, this)
                  else
                     EqualityResult.notEqual(actual, expected, this)
               }
            }
            listOf("apple", "Apple") should containExactlyInAnyOrder(listOf("APPLE", "APPLE"), caseInsensitiveStringEquality)

we could:

  • just remove custom verifier
  • replace verifier with a mapper (value: T) -> mappedValue: U and map all elements in both collections before comparison
  • try to fix it while keeping the signature, which might be challenging

What should we do?

@LeoColman LeoColman added bug 🐛 Issues that report a problem or error in the code. question ❓ Inquiries or clarifications needed about the project. assertions 🔍 Related to the assertion mechanisms within the testing framework. labels Jan 25, 2024
@Kantis
Copy link
Member

Kantis commented Feb 3, 2024

I think we should deprecate the method accepting the custom verifier. I think it's a bit problematic in this method.. My reasoning is as follows..

Given a custom verifier, there's no guarantees that the equality implementation is associative. Normally A == B and B == C implies that A == C. That might not be the case depending on how a user implements their verifier. This becomes a problem when implementing containsExactlyInAnyOrder.

When associativity applies, we can simply find any match to an element and it's equally fine to "consume" that match and move on and check if the rest of the elements manage to find a match. If all elements find a match, the assertion is a success.

Without associativity, we need to test every permutation of pairing the elements of the lists, otherwise we might end up with a false negative assertion.

@Kantis
Copy link
Member

Kantis commented Feb 4, 2024

Just noticed that this duplicates #3820 and a PR to fix it in #3821.. Will review that and contemplate for a bit.

@AlexCue987
Copy link
Contributor Author

Just noticed that this duplicates #3820 and a PR to fix it in #3821.. Will review that and contemplate for a bit.

I believe that fix won't work, and left a comment there explaining why.

@AlexCue987
Copy link
Contributor Author

we'll keep the signature as is, working on a fix now

@AlexCue987
Copy link
Contributor Author

the fix #3976

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assertions 🔍 Related to the assertion mechanisms within the testing framework. bug 🐛 Issues that report a problem or error in the code. question ❓ Inquiries or clarifications needed about the project.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants