Assertion shouldBe succeeds even when equals() always returns false
See original GitHub issueHere’s a simple class that implements a Set
interface and always returns false
from its equals()
method. That should mean that every shouldBe
assertion fails, right?
In my case, using kotest 5.1.0, first two tests succeed, and the last one fails - it seems kotest is doing something else instead of using the equals()
method.
Is this a bug, or just unexpected behavior? If so, is there an assertion that always uses the equals()
method?
class ArraySet(vararg items: String) : Set<String> {
private val items: Array<String> = items.distinct().toTypedArray()
override val size get() = items.size
override fun iterator() = items.iterator()
override fun contains(element: String) = items.contains(element)
override fun containsAll(elements: Collection<String>) = items.toList().containsAll(elements)
override fun isEmpty() = items.isEmpty()
override fun equals(other: Any?): Boolean = false
override fun hashCode(): Int {
return items.sumOf { it.hashCode() }
}
}
class ArraySetTest : FunSpec({
val o1 = ArraySet("foo", "bar")
val o2 = ArraySet("bar", "foo")
val o3 = ArraySet("foo", "bar")
val o4 = ArraySet("foo, bar, baz")
test("1. equal up to permutation") {
o1 shouldBe o2
}
test("2. completely equal") {
o1 shouldBe o3
}
test("3. different elements") {
o1 shouldBe o4
}
})
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Why does String equals() return false (custom Comparator ...
I'm having trouble finding the reason why (s1.equals(s2)) returns false even when the two strings s1 and s2 contain the same value. Eclipse...
Read more >Assertions - Go Packages
Package assert provides a set of comprehensive testing tools for use with the normal ... Equal(t, a, b, "The two words should be...
Read more >Programming With Assertions - Oracle Help Center
When the system runs the assertion, it evaluates Expression1 and if it is false throws an AssertionError with no detail message.
Read more >Writing an equals method - how hard can it be?
In the first assertion, we are calling a method with signature equals(Object) on an object with compile-time type Point . As Point does...
Read more >Equals and hashcode implementation considerations
@Override public boolean equals(Object o) { if (this == o) { (1) return true; } if (o == null || getClass() != o.getClass())...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I think shouldBe should (and does) use equals except where we override it for special behavior - like we are doing for sets for example.
This example is failing because I think we are using the iterator methods of set, and thus not the equals behavior. We should document all the special cases for shouldBe. And after that I can add lint rules to the kotest plugin to warn you.
There is the EqualityMatcher already, I think we’re just missing the infix functions
kotest-assertions/kotest-assertions-shared/src/commonMain/kotlin/io/kotest/assertions/eq/DefaultEq.kt:14
This is the default equality matcher, it uses
==