shouldBe does not handle java long or Long but does handle Integer

[jillesvangurp]

Getting a unexpected assertion failure while converting assertj assertions to kotlin-test shouldBe style assertions.

Given this simple Java class:

public class Foo {
    public static final long MEANING_OF_LIFE = 42l;
}

This test fails with the above on the shouldBe line:

import io.kotlintest.shouldBe
import org.assertj.core.api.Assertions
import org.junit.jupiter.api.Test

class FooTest {
    @Test
    fun fooTest() {
        val v1: Int = Foo.MEANING_OF_LIFE.toInt()
        val v2 = java.lang.Integer.valueOf(42)
        val v3 = Foo.MEANING_OF_LIFE
        val v4 = java.lang.Long.valueOf(42)
        val v5 = Foo.MEANING_OF_LIFE.toLong()

        // assertj works for all cases
        Assertions.assertThat(v1).isEqualTo(42)
        Assertions.assertThat(v2).isEqualTo(42)
        Assertions.assertThat(v3).isEqualTo(42)
        Assertions.assertThat(v4).isEqualTo(42)
        Assertions.assertThat(v5).isEqualTo(42)

        // works
        v1 shouldBe 42
        // works
        v2 shouldBe 42
        // fails
        v3 shouldBe 42
        // fails
        v4 shouldBe 42
        // fails
        v5 shouldBe 42
    }
}

with:

java.lang.AssertionError: expected: 42 but was: 42
Expected :42 
Actual   :42

So, it seems the only way I can make this work is calling toInt(). This seems to result from differences in the way kotlin numeric types differ from Java as explained here: https://kotlinlang.org/docs/reference/basic-types.html. But it makes testing Java code with Kotlin a bit more challenging. So, it might be worth investigating some kind of workaround and make shouldBe a bit more foregiving by maybe handling java primitive and boxed type explicitly.

[jillesvangurp]

Similar issues with doubles, I have to call toDouble() on them to make things work; toFloat() does not work.

[sksamuel]

I've added a quick fix and some tests. Basically I promote ints to longs, and floats to doubles where appropriate.

See 48182db

[jillesvangurp]

I'm an idiot, kotlin literals are Int unless you type 42L. Java has type conversions that kotlin does not have. Still, might be valid for shouldBe to be more foregiving. But otherwise the solution is to use the correct literals.

[sksamuel]

Yes, but the Java use case is a valid one.

[sksamuel]

Fix is applied in latest release 3.1.5