Is resetting a mock/overriding interactions an anti-pattern?

[leonard84]

Continuation of this conversation on Stackoverflow.

import spock.lang.*

class ASpec extends Specification {
  List myList = Mock()
    
  def setup() {
    myList.get(0) >> 1
  }
    
  def "default behavior"() {
    expect: 
    myList.get(0) == 1
  }
    
  def "override behavior"() {
    when:
    def result = myList.get(0)

    then:
    myList.get(0) >> 42
    result == 42
  }
}

Great answer, thanks. This is kind of mentioned in passing here in the context of interactions. Good to know that it works for plain stubbing, too. Asking you as a maintainer: Is this something Spock users should rely on and even use as a tool? I can kind of see why the OP wants this, but actually it does not make the spec more readable. I would at least comment it, if using it at all. – @kriegaex

You normally use it for combined mocking assertions with stubbing, and currently it is the only way to do this. There are some attempts to change this, but they all have other drawbacks. So, if you have a mock use _ * mock.method() >> value if you only have a stub you have to leave the interaction count out and just do stub.method() >> value in the then block.

Yes, I know that it is used for combining mocking + stubbing (or stubbing + verifying interactions), and I regularly use it for that matter. Trying to do that separately is a frequent error among Spock users, because it is so counter-intuitive. But it is documented as a caveat, so it is fine. My question was about actively using what normally is an anti-pattern in order to override peviously stubbed methods. Is this a usage pattern you would recommend or actively promote? – @kriegaex

I wouldn't call overriding an interaction an anti-pattern per se. There are certainly cases where it is the smaller code smell. For example, you have a large spec in which 10+ features all require the same stubbing and then you want to test one error use-case where you have to change the interaction to something else. You could move the stubbing from the setup to its own method and call that one in all 10+ feature's given blocks, or you leave it in the setup and override the interaction in that one exceptional feature.

The solutions proposed - as an alternative to the then-block interactions - so far was to invert the order in which Spock would match interactions, from match first to match last.

Here is a list of related issues #26, #251, #321, #962, #1219, and #1308

[kriegaex]

OK, I see that 8 years ago Peter already called this "a feature, not a workaround", cf. #26 (comment). The sheer number of issues you quoted above and questions on StackOverflow or elsewhere shows however, that this is one of the most counter-intuitive parts of Spock, whereas intuitivity is usually Spock's strong suit. I think that having to know the default behaviour as documented is OK for an advanced use case like this. But a way to explicitly override stubbing and/or interactions would definitely be a plus. I have seen the open PRs and am not sure if they are universal solutions, but I have not analysed them in detail either.

I am feeling it is kind of a weak proposition on my part to say "it is not nice the way it is" without suggesting something better in more concrete terms

• without breaking backward compatibility (even though that might be acceptable if documented clearly, because the number of use cases to migrate should be small for most given projects),
• taking into consideration how and in which compilation phase Groovy AST takes place.

My feedback simply is: If something could be done here in order to improve the situation, it might be worth for the Spock team to spend some time thinking about this issue and designing a better solution.

[leonard84]

But a way to explicitly override stubbing and/or interactions would definitely be a plus.

Well it exists, as I've shown above, it may not be as intuitive but it is explicit. Any interaction defined in the then block´, has precedence over interactions defined in the initializer/setup/given-block.

I think we can definitely improve the docs and I would propose that _ * stub.method() >> result should be the format used, it is basically the same as stub.method() >> result, but it fits better with the other interactions. As this is already possible, it has not breaking changes and works reliably.

---

Alternatively, we could add an additional interaction scope at the start of a feature and close it at the end. This would give interactions in the given-Block precedence - making it a breaking change.

Where would you put those overrides when you have a second when-then block, in the when or then? If they should go into the when-block, then we'd need to enhance to AST transform to also add interaction scopes if there are only interaction defined in the when-block but not in the then-block. This might lead some people to put the mock interactions also in the when-blocks, where we definitely don't want them.

I don't really know if that would make it better or just more confusing.

[kriegaex]

I agree with your reasoning. Until we have a better idea and/or a more convincing use case for doing any major changes, I am also convinced now that improving the docs is the best way to move forward and reap some benefit from the seeds we sowed in this conversation.