https://kotlinlang.org logo
Join Slack
Powered by
a test like ``` @Test fun testFoo() { ...
# javascript
t
a test like
Copy code
@Test
    fun testFoo() {
        val a: Long = 6
        val b: Long? = createFoo()
        assertEquals(a, b)
    }

    fun createFoo(): Long? = if (true) 5 else null
fails with 
jsNodeTest
- that makes it impossible to make use of the new features 😞
any ideas on that?
i
Hello, this test is failed, because of 
6 != 5
or do you have build fails? I can’t reproduce it
t
yeah of course its 6 , sorry, it's a tsest like that . sorry for the confusion
also it is LIKE that. i cannot debug it any further because the new mocha stuff doesn't allow debugging it
so i have a method that wil lfinally return a 
Long?
and i check for a conrete 
Long
mocha AssertionError: Expected <1574428268710>, actual <1574428268710>
aaand i just found out the information i got yesterday is wrong: one can set a flag on the testTask 
debug=true
and remote debug the test with chrome
the debugger tells me actual is 
Kotlin.Long {low_: -1824411265, high_: 366}
and expected is 
Kotlin.Long {low_: -1824411265, high_: 366}
yes assertEquals fails
i
Unfortunatelly now because of tests are run on Mocha, it will run 
--inspect-brk
on mocha and actually you can “debug” mocha instead of test script. Do you set debug property and it debugs test script?
t
if you set a breakpoint in the testcode its easy to debug it
so but still assertEquals fails with to identical long objects... now what can i do? 😕
i
if you set a breakpoint in the testcode its easy to debug it
Wow! That’s good 🙂
so but still assertEquals fails with to identical long objects... now what can i do? 😕
On my project, test is passed, could you please share your project?
Copy code
@Test
  fun testFoo() {
    val a: Long = 6
    val b: Long? = createFoo()
    assertEquals(a, b)
  }

fun createFoo(): Long? = if (true) 6 else null
t
it's just a demontration what happens - that was before i knew how to debug the test. now i can tell you: i have to distinct, yet identical kotlin.Long objects and the assertEquals assertion fails
the debugger now revealed the problem: while 
console.log(other)
prints 
Kotlin.Long
other instanceof Long
prints false
that why 
this.equals(other)
fails
any idea why 
instanceof
would fail? what does 
instanceof
? i mean i can SEE IN THE DEBUGGER it's a 
Kotlin.Long
- still the check faiils
also 
equalsLong(other)
evaluates to true. it's only the 
instanceof
check that fails
b
other instanceof Long
false iff other’s prototype isn’t 
Long
, you could get such object after serialaze and deserialaze, for example
t
how can i check the prototype? i can see it is set and initlaized and "looks" correctly
also: if it's wrong, why is it ALWAYS wrong running with mocha, but NEVER with jest?
b
you can take a look to 
__proto__
properti of object
or use 
Object.getPrototypeOf(expr)
Do you have simple project to reproduce?
t
Unfortunately Not. Creating 2 longs with the same properties didn't reproduce it:-(
b
Have you check 
other.__proto__
?
t
I did - both are set so at least we can sure that both are objects created by kotlin.
b
Does 
other.__proto__ === Long
return 
true
?
Result of these expressions 
a.__proto__ === Long
and 
a instanceof Long
must be same for the same 
Long
.
t
neither 
other.__proto__ === Long
nor 
this.__proto__ === Long
evaluates to true
although i had to use 
Kotlin.Long
or else i'd get an error that 
Long
cannot be found
(still 
this instanceof Kotlin.Long
is true)
it's getting even MORE confusing. the actuial value that is or is not a Long is the result of 
com.soywiz.klock.DateTime.nowUnixLong()
while this IS 
instanceof Long
the actual value returned walks through a code passage where 
Kotlin.Long
is not declared and a soon as it reaches the test code where 
Kotlin.Long
is declared again, 
value instanceof Kotlin.Long
evaluates to false
so in the end 
assertTrue(com.soywiz.klock.DateTime.nowUnixLong() is Long)
seems to always fail when run with mocha
is there a way to get the compile TEST js code?
guys really wtf? 
DateTime_0.Companion.nowUnixLong() instanceof Kotlin.Long
-> 
false
the method is declared as
Copy code
DateTime$Companion.prototype.nowUnixLong = function () {
    return Kotlin.Long.fromNumber(KlockInternal_getInstance().currentTime);
  };
otlin.Long.fromNumber(KlockInternal_getInstance().currentTime) instanceof Kotlin.Long
-> 
true
how is that even possible? how can returning a value change its type?
b
Whould be nice if you could provide self-contained example to reproduce.
Do you run it inside browser? Maybe you are transfering objects beetween iframes?
t
the test is as easy as
Copy code
import kotlin.test.Test
import kotlin.test.assertTrue


class Foo {
    @Test
    fun foo() {
        assertTrue(com.soywiz.klock.DateTime.nowUnixLong() is Long)
    }
}
i can provide a full gradle project, if necessary. as you can see there is no object passing involved. it's a plain nodejs test
one could argue that this is actuall worth a bug reporting against klock. but in fact i don't belive it's a bug there, as the debugger clearly shows on the js side a 
Kotlin.Long
is constructed
i created a repository contianing two more tests https://github.com/mschirmacher/wtf
so the first test is the ne actually failing in our production code, too. the next two tests replicated the very same bevahior, happening in the method called in the first test - and they do not fail!
i found the problem: klock uses a different Kotlin.Long then the rest of the application.
i will ask the question for a solution in a new thread
b
you’re right, you are using kotlin 1.3.60 but klock depend on 1.3.50, so klock and your program use different runtimes
@Ilya Goncharov [JB] do you have any sugestion?
@Ilya Goncharov [JB] rolling back to 1.3.50 doesn’t help due a bug there — wrong path to test.js, is it know fixed issue?
t
i don't know why i wrote 1.3.50 - klock depends on 1.3.31
i
Seems that while in 1.3.60, tests run, wrong path apparently was bug, but now it fixed (I hope) @bashor As I can see, klock 1.8.0 is compatible with Kotlin 1.3.60, but you are right, there is another Kotlin runtime
Seems that it is klock issue, I can find 
package.json
in its artifact with block 
dependencies
with written kotlin 1.3.50
image.png
You can try to use this workaround in 
build.gradle.kts
, it deletes 
node_modules
for klock after Npm install It remove the second Kotlin runtime for only klock, and it will uses common runtime But it is hacky (and only temporary solution), better to report about problem to klock maintainers
Copy code
tasks.getByName("kotlinNpmInstall") {
    doLast {
        File("$buildDir/js/node_modules/klock-root-klock/node_modules").deleteRecursively()
    }
}
t
well, but still, if it they put the wrong version on the 
package.json
i would end up with the dependency on kotlin.js twice and get the very same error, wouldn't i?
btw: this workaround seems to work - thx for that!
yet now i am unsure what to do next? where would i file an issue?
i
> yet now i am unsure what to do next? where would i file an issue? I suggest that GitHub issues is good for this (https://github.com/korlibs/klock/issues) and I should “like” your issue 🙂 > well, but still, if it they put the wrong version on the 
package.json
i would end up with the dependency on kotlin.js twice and get the very same error, wouldn’t i? The main problem, that gradle don’t look at 
package.json
, we install npm dependencies via Yarn. When we unzip gradle dependency with klock, it unzipped with bundled 
package.json
and them npm dependencies. For gradle they have no kotlin dependency, but in fact for JavaScript world there is. And that’s why we have no any compilation or build problem and get error only in runtime. Because the problem is that in runtime we have 2 kotlin’s versions.
t
thanks for your help!
d
Just checked this. Is including a 
package.json
file recommended at all? I included because some people wanted to use it with npm: https://github.com/korlibs/klock/issues/54 but might not be a good idea, or something generated by the kotlin gradle plugin? Not sure. I could add the delete stuff but looks a bit hacky. Any suggestions here?
i
Publishing with package.json is not implemented yet, but it is in our plans. It is ok to include package.json, but need to think about “Kotlin/JS” dependencies, maybe better to declare it as a peerDependencies It forces user to declare Kotlin/JS dependent modules versions explicitly and only once, so will not be problem with different runtimes because of transitives
👍 1
d
Nice, I’ll do the peerDependencies. Thanks for the suggestion!
t
very cool - any idea when you will find the time for a new release? 🙂
d
later today
t
awesome! thank you very much ❤️
5 Views
Open in Slack
PreviousNext
Powered by