Test Mixins

[robfletcher]

Originally reported on Google Code with ID 218

There are situations where a bunch of tests should be applied to a code base. We are
currently using derived classes which is a pain, especially when your code under tests
should support either only a subset or  multiple category of tests (which results in
many abstract base specs and many concrete specs for the code under test ...)

This could be solved with test mixins in an elegant way. Here is an example 

class SpecMixin (extends SpecificationMixin?) {

  def "test something"() {
    when:
    objectUnderTest.doSomething()
    then:
    objectUnderTest.somethingDone()
  }

}

@Mixin(SpecMixin)
class RealSpec extends Specification {
  def objectUnderTest = new ObjectUnderTest()
}

The mixin, as well as the test should be able to access properties (as done with objectUnderTest
in this example) and the test lifecycle methods should be mixed in as well.

Reported by peter.rietzler@gmx.net on 2011-12-02 18:16:03

[robfletcher]

I agree that this will be a killer feature. We've wanted to have it for a long time.
Any volunteers to implement it? :-)

Reported by pniederw on 2011-12-13 19:38:39

• Status changed: Accepted

[robfletcher]

Reported by pniederw on 2012-02-17 03:04:31

• Labels added: Milestone-0.7

[robfletcher]

Reported by pniederw on 2012-10-04 06:46:04

• Labels added: Milestone-1.0
• Labels removed: Milestone-0.7

[robfletcher]

Try grails.test.mixin.TestMixin

Code will be:
@TestMixin(SpecMixin)
class RealSpec extends Specification {
  def objectUnderTest = new ObjectUnderTest()
}

Reported by karsten.telling.nielsen on 2013-11-07 16:21:10

[robfletcher]

This issue is about a general solution for Spock, not a Grails-specific one.

Reported by pniederw on 2013-11-07 16:27:54

[robfletcher]

I have tried to provide a setup/setupSpec method through a Groovy Mixin. While I can
provide certain behaviour through inheritance, it turns out to be a bit limited when
various categories of tests (integration, unit test, ...) require a very different
test setup. Essentially the class tree will "explode".

Generally I have experienced that Mixins/Delegates are not very helpful with Spock
specifications. For example I also tried to add a Mixin that provided a specification
with a Spring @Autowired target that was not recognized by Spring. I assume that is
due to the way Mixins are implemented in Groovy?

Reported by Martin.Ahrer on 2014-02-18 08:45:08

[robfletcher]

Groovy mixins are only visible to Groovy code, and they never appeared to work well
for me. If I'm not mistaken, there is a way to bring annotations across when using
`@Delegate`. Then again, `@Delegate` might not play well with other AST transforms,
such as Spock's.

Reported by pniederw on 2014-02-20 01:10:22

[robfletcher]

Reported by pniederw on 2015-03-01 23:45:49

• Labels added: Milestone-1.1
• Labels removed: Milestone-1.0