Add a preview feature for interaction-based testing support

[pshevche]

Why does this matter?

Spock provides a powerful mechanism for interaction-based testing (documentation). In this story, we should explore adding this support to Spockk. Since the problem statement is rather broad, this iteration of Spockk will provide a preview of what the support would look like. A secondary goal is to have a proof-of-value to be shared with Spock team to justify integrating Spockk into Spock core framework. In particular, this preview will focus on a simple mock-based interaction:

• Users can create a mock object.
• Users can assert interactions on the mock method.
• Users can create and configure a stub object.
• Users can define behaviors of methods for stub objects.
• Users can assert interactions on the stub methods.

What should developers be able to write?

Spock heavily utilizes the right shift operations for defining return values of mocked methods. This is not possible in Kotlin, so finding an ergonomic syntax should be one of the goals of this preview. The following shows an example of what this syntax may look like, but it is not final.

class InteractionsTest : Specification() {
  def "mock preview feature"() {
    given
    val obj = Mock(Person::class.java)

    expect
    1 * obj.setName(_)
  }

  def "stub preview feature"() {
    given
    val obj = Stub(Person::class.java) {
       setUsername(_) does {
         println("setUsername called")
       }
    }
   
   when
   println(obj)
   
   then
   1 * obj.getUsername() returns "Name"
  }
}

Acceptance criteria

• Users can define Spock-like interactions with Mocks and Stubs

How does Spock implement this?

To be researched.

Additional context

• Focus on simple interaction patterns first: don't support cadinality matchers or other more advanced features.
• Core features to support are: declaring Mocks and Stubs, defining simple conditions for the number of interactions, define custom behavior and return values for stubbed methods, capture arguments in interactions.
• The feature should be disabled by default. The existing MockingApiTransformer should also be disabled by default.
• The feature enablement mechanism will be implemented as part of Add support for implicit assertions combined with power assert plugin #201. Therefore, this feature depends on it.