Open igorwojda opened 5 years ago
This is a good idea!
At the moment we're using assertEquals
from kotlin.test
, which does the comparison and failure message internally, so we would have to write our own implementation
hello, Is this issue up for grabs? can I take this up?
hello, Is this issue up for grabs? can I take this up?
Feel free to take it :-)
here is a real-life scenario that made me very confused
The reason of the confusion was this error message :
java.lang.AssertionError: Expected <[1, 2, fizz, 4, buzz]>, actual <[1, 2, fizz, 4, buzz]>.
I think we should consider custom
toString
conversion to make distinction Int vs String more explicit for all "string prints". The code is not the best but we will get the idea:As a result we would get much better error message giving instant hint what is wrong Before:
java.lang.AssertionError: Expected <[1, 2, fizz, 4, buzz]>, actual <[1, 2, fizz, 4, buzz]>
After
java.lang.AssertionError: Expected <[1, 2, fizz, 4, buzz]>, actual <["1", "2", "fizz", "4", "buzz"]>
As an alternative we could consider handling in special wahy the case where test fails but
actuall.toString() == expected.toString()
. Then we could make decision about display more information like data types in error message.Also, keep in mind this is a simplified example, in reality, we will have a function that returns the list making mistake harder to spot in code
listOf(1, 2, "fizz", 4, "buzz") shouldEqual getMyList() //fail