https://kotlinlang.org logo
Join Slack
Powered by
Hi people, I work on KMP project. And unit tests a...
# javascript
e
Hi people, I work on KMP project. And unit tests are failing for JS version with similar error
Copy code
AssertionError: Expected <1>, actual <1> is not same.
	at Object.captureStack(/tmp/_karma_webpack_16032/commons.js:100023)
	at AssertionError.constructor(/tmp/_karma_webpack_16032/commons.js:100325)
	at <global>.new AssertionError(/tmp/_karma_webpack_16032/commons.js:100522)
	at DefaultJsAsserter.assertTrue(/tmp/_karma_webpack_16032/commons.js:61035)
	at DefaultJsAsserter.Asserter.assertSame(/tmp/_karma_webpack_16032/commons.js:60849)
	at DefaultJsAsserter.assertSame(/tmp/_karma_webpack_16032/commons.js:61016)
	at <global>.assertSame(/tmp/_karma_webpack_16032/commons.js:60213)
	at com.badoo.reaktive.completable.RetryTest.predicate_receives_valid_counter_WHEN_upstream_produces_error(/tmp/_karma_webpack_16032/commons.js:3616)
	at <global>.<unknown>(/tmp/_karma_webpack_16032/commons.js:30474)
	at Context.<anonymous>(/tmp/_karma_webpack_16032/commons.js:60011)
I assume there is wrong equals is used. However, I’m not JS developer so don’t have any clue where to look to unblock me. The same tests are not failing when I run them in IDE.
p
Indeed looks weird. A minimal reproducer would be cool.
Please also share show exactly you run the tests through IDE - via Gradle? If yes, we should be able to lead to a situation where this error is reproducible in the IDE. Then you could use a debugger.
e
I run test in IDE via UI and from run UI it looks like it runs test via the gradle
p
what Gradle command does the IDE show? what happens if you try to run it verbatim in the console?
a
Could you point to the code that is failing? JS numbers are a bit wierd.
e
I will send the code now
So I see that this branch is changed parameter type from Int to Long
The failing test is
Copy code
@Test
    fun predicate_receives_valid_counter_WHEN_upstream_produces_error() {
        val timeRef = AtomicLong()
        upstream
            .retry { time, _ ->
                timeRef.value = time
                true
            }
            .test()
        upstream.onError(Throwable())
        assertSame(timeRef.value, 1)
        upstream.onError(Throwable())
        assertSame(timeRef.value, 2)
    }
a
You are using a non-standard asserter. Does it even work on JS? As for the code, you are compating Long and Int. JS does not have native support for Longs, they are emulated by Kotlin. So yes, those values are different.
e
Cool!
The assert works
I still wonder it works on my machine. And let me try to fix with adding L suffix.
@altavir BTW, these assertions are coming from kotlin test library
a
I thouthg it should be assertEquals
e
Agree that equality should be the more correct check
Will 
assertEquals
work with comparing int and long in JS?
I tried on my machine and it works. Let see if CI will run it also correctly.
a
Not sure, but it should give a warning that types are not same
e
Looks like CI is also happy
i
You shouldn't compare int and long and expect equality. Also, you shouldn't use assertSame to compare numbers because they have no stable identity.
The test passes because I suppose 1 and 2 are not ints - they are integer literals, that get their type inferred to Long, as it is the expected type from the other parameter of assertEquals call in the test.
e
I would expect equality between int and long in the range where they overlap
a
And how will it work when you swap places? Or how will Double and Float equality work. In kotlin most of automatic type coercions are prohibited and it is very good because there are a lot of errors coming from it.
e
I’m not sure Double and Float are good analogy
I was thinking from mathematical point of view that 1 is 1 doesn’t matter which type is used. If I look from software writing side, maybe I want to be strict also about types that represent the number.
a
I will give an English variation of my Joker conference talk about mathematics soon. And the point is that numbers can mean different things in different cases.
e
Please share the link - it would be interesting to watch it
a
I will drop an announce in #mathematics when we know the date. Or you can listen to the talk in Russian if you have a JUG ticket.
But the talk is mostly about operations. For type comparison all you need to remember is that equality does not always mean the same thing. I believe that Kotlin team now wants to add more relaxed type coercion for literals, but not for dynamic values.
6 Views
Open in Slack
PreviousNext
Powered by