Spock：final类的mocking/stubing void方法

Question

这里的模拟类是org.apache.lucene.document.textfield。setStringValue是void。

我的规格是这样的...

given:
    ...
    TextField textFieldMock = GroovyMock( TextField )
    // textField is a field of the ConsoleHandler class, ch is a Spy of that class
    ch.textField = textFieldMock
    // same results with or without this line: 
    textFieldMock.setStringValue( _ ) >> null
    // NB I explain about this line below:
    textFieldMock.getClass() >> Object.class

对应的app代码看起来是这样的：

    assert textField != null
    singleLDoc.add(textField)
    writerDocument.paragraphIterator.each{

        println( "textField == null? ${ textField == null }" )
        println( "textField ${ textField.getClass() }" )

        textField.setStringValue( it.textContent ) // NB this is line 114
        indexWriter.addDocument( singleLDoc )

println的输出为

textField == null? false
textField class java.lang.Object

textField == null? false
textField null

java.lang.NullPointerException
at org.apache.lucene.document.Field.setStringValue(Field.java:307)
at org.spockframework.mock.runtime.GroovyMockMetaClass.doInvokeMethod(GroovyMockMetaClass.java:86)
at org.spockframework.mock.runtime.GroovyMockMetaClass.invokeMethod(GroovyMockMetaClass.java:42)
at core.ConsoleHandler.parse_closure1(ConsoleHandler.groovy:114)

在我看来，似乎发生了一些有趣的事情：好像Spock在自言自语：“啊，这个类TextField是Final，所以我将咨询它的父类，并从那里使用方法SetStringValue...我发现/决定它不是一个模拟...”

为什么setStringValue没有被嘲弄（或“替换”或任何正确的方法术语...）？

稍后

我去看了一下这个包中的field.java。相关的行有：

  public void setStringValue(String value) {
    if (!(fieldsData instanceof String)) {
      throw new IllegalArgumentException("cannot change value type from " + fieldsData.getClass().getSimpleName() + " to String");
    }
    if (value == null) {
      throw new IllegalArgumentException("value must not be null");
    }
    fieldsData = value;
  }

...第307行（涉及NPE）是第一个抛出新的IllegalArgumentException...行。挺奇怪的。提示fieldsdata为null（如您所料）。

但是为什么Spock会发现自己正在处理类field中的这段代码呢？不合逻辑：这是嘲弄，吉姆，但不是我们所知道的。

PPS解决方案我没有得到任何结果，最后只是创建了一个包装类，它封装了有问题的finaltextfield（并将生成所需的任何方法……)。

我在过去有过与Lucene类作斗争的经历：这些类中的许多都是final或具有final方法。在任何人提出您不需要测试已经可以信任的包之前（我同意这一点！），您仍然需要在开发代码时测试您自己对此类类的使用。

Answer 1

我真的无法解释为什么它不能像预期的那样为您工作--顺便说一句，截短getClass()是一个坏主意，也是一个坏例子，因为它可能会产生各种副作用--但我确实有一个解决方法给您：使用全局模拟。

第一个特征方法复制了有问题的测试用例，第二个方法展示了如何解决它。

package de.scrum_master.stackoverflow

import org.apache.lucene.document.TextField
import spock.lang.Specification

class LuceneTest extends Specification {
  def "Lucene text field normal GroovyMock"() {

    given: "normal Groovy mock"
    TextField textField = GroovyMock() {
      stringValue() >> "abc"
    }

    when: "calling parent method"
    textField.setStringValue("test")

    then: "exception is thrown"
    thrown NullPointerException

    and: "parent method stubbing does not work"
    textField.stringValue() == null
  }

  def "Lucene text field global GroovyMock"() {

    given: "global Groovy mock"
    TextField textField = GroovyMock(global: true) {
      stringValue() >> "abc"
    }

    expect: "can call parent method"
    textField.setStringValue("test")

    and: "parent method stubbing works"
    textField.stringValue() == "abc"
  }
}