Question

如果我们想测试一个类型的扩展函数，我们可以创建这种类型的实例，调用该函数并检查返回的值。但是如何测试类中定义的扩展函数呢？

abstract class AbstractClass<T> {
    fun doStuff(): T = "Hello".foo()

    abstract fun String.foo(): T
}

class SubClass1: AbstractClass<Int>() {
    override fun String.foo(): Int = 1
}

class SubClass2: AbstractClass<Boolean>() {
    override fun String.foo(): Boolean = true
}

我们如何在类foo()和SubClass1中测试方法SubClass2的逻辑？它甚至可能吗？

我知道我可以改变设计来测试它。我有两种可能性：

不要使用扩展功能。 ¯\ _（ツ）_ /¯

abstract class AbstractClass<T> {
    fun doStuff(): T = foo("Hello")

    abstract fun foo(string: String): T
}

class SubClass1: AbstractClass<Int>() {
    override fun foo(string: String): Int = 1
}

然后我们可以创建一个对象SubClass1，调用foo()并检查返回的值。

创建具有internal可见性的其他扩展功能，以测试逻辑。
```
class SubClass1: AbstractClass<Int>() {
    override fun String.foo(): Int = internalFoo()
}

internal fun String.internalFoo(): Int = 1
```
然后我们可以创建一个对象String，调用internalFoo()并检查返回的值。但是，我不喜欢这个解决方案，因为我们可以改变override fun String.foo(): Int的主体，我们的测试就会通过。

那么，是否可以在类中测试扩展函数？如果没有，您将如何更改设计以测试其逻辑？

Answer 1

由于测试应该从客户的角度编写，我不确定它是否是有效的测试。但我确实提出了一种方法来测试它。

@Test
fun `test extension function`() {
    var int = 0

    SubClass1().apply {
        int = "blah".foo()
    }

    assertThat(int, `is`(1))
}

Answer 2

扩展方法很棒，它们可以实现像LINQ，Android KTX中那样流畅的语法。

但是，扩展方法不适用于子类化。这是因为扩展基本上是non-object-oriented。它们类似于Java中的静态方法，可以隐藏但不会在子类中重写。

如果您希望在子类中更改某些代码，请不要编写扩展方法，因为您将面临在问题和all of the disadvantages that static methods brings to testability中遇到的测试障碍。

你的第一个例子绝对没有错，也没有理由坚持那里的扩展方法：

abstract class AbstractClass<T> {
    fun doStuff(): T = foo("Hello")

    abstract fun foo(string: String): T
}

class SubClass1: AbstractClass<Int>() {
    override fun foo(string: String): Int = 1
}

测试类内的扩展函数

2 个答案: