spockframework / spockframework/spock

Detached Spock Mock with Groovy Closures initialisation

Open
#1,732 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

new feature
Dominant language
Java
Stars
3.6k
Forks
483
PR merge metrics
No merged PRs in 30d

Description

Is your feature request related to a problem?

We have been using Spock framework in writing our test suite and it saves us a lot of the Java boilerplate using Groovylang. However, we had to repeatedly write the same mocks in different application services.

A common approach in JUnit was to write mock helpers where test fixtures are defined. This makes it cheaper to write unit tests.

However, I am aware detached mocks should be attached to a specification in order to use interactions. This makes writing mock fixtures not possible, such as:

class DetachedMockFactorySpec extends Specification {
  def test() {
    given:
    def sut = new SubjectUnderTest(MockUtils.defaultMockCustomerRepository())
    
    then:
    ...
  }

Currently, I know we can write detached mocks as follows:

interface IMockMe {
  int foo(int i)
}

class DetachedMockFactorySpec extends Specification {

  @Subject
  DetachedMockFactory factory = new DetachedMockFactory()

  def "Mock(class)"() {
    given:
    IMockMe mock = factory.Mock(IMockMe)
    attach(mock)
    mock.foo(_) >> 2

    expect:
    mock.foo(2) == 2

    cleanup:
    detach(mock)
  }
}
Describe the solution you'd like

Is it possible to write it as?

class DetachedMockFactorySpec extends Specification {

  // DetachedMockApi acts as a proxy
  @Subject
  DetachedMockApi mock = new DetachedMockApi(new DetachedMockFactory(), this)

  def "Mock(class)"() {
    given:
    // attach and detach is called internally by the proxy api
    IMockMe mock = mock.Mock(IMockMe)
    mock.foo(_) >> 2

    expect:
    mock.foo(2) == 2
  }
}
Describe alternatives you've considered

No response

Additional context

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Review DetachedMockFactory and the existing attach(mock)/detach(mock) usage shown in the issue before assessing the proposed DetachedMockApi. The work is done when detached mocks can be created through the proxy while attachment and detachment happen internally, without requiring those calls in each specification.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
testing
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.