How to test multiple implementations

[blazmrak]

Hi, is there a way to specify implementations the object under test without extending the spec multiple times?

What I have right now is something like this:

abstract class Spec extends Specification {
  def sut = init()

  protected abstract SUT init()

  def featureA() {...}
  def featureB() {...}
}

class ImplSpec extends Spec {
  @Override
  protected SUT init() { return new SUTImpl() }
}

But I think that refactoring this into multiple specs for each feature would make things more readable, so I did something like this:

abstract class Spec extends Specification {
  def sut = init()

  protected abstract SUT init()
}

abstract class SpecA extends Spec {
  def featureA() {...}
}

abstract class SpecB extends Spec {
  def featureB() {...}
}

The problem I have is that I would have to extend SpecA and SpecB and provide the same implementation in init() like so:

class ImplSpecA extends SpecA {
  @Override
  protected SUT init() { return new SUTImpl() }
}

class ImplSpecB extends SpecB {
  @Override
  protected SUT init() { return new SUTImpl() }
}

The best I was able to do was this:

trait ImplSpec {
  SUT init() { return new SUTImpl() }
}

class ImplSpecA extends SpecA implements ImplSpec {}

class ImplSpecB extends SpecB implements ImplSpec {}

This turns ugly quickly. I would ideally want something like this:

@Using([SUTImpl1, SUTImpl2])
class SpecA extends Spec {
  def featureA() {...}
}

@Using([SUTImpl1])
class SpecB extends Spec {
  def featureB() {...}
}

Is this possible (and if possible, how?) or am I super abusing Spock?

[leonard84]

That is currently not possible, and even with #1153 you'd end up having to repeat the sut declarations if you want to split per feature. The current recommended way, is what you have described.

Individual specs have other advantages as well, i.e., they can be executed in isolation, and the test-retry plugin also only works on classes.

[blazmrak]

Wait, what is the state of #1153? The major issue for me is that I have no idea how Spock actually works internally. I have had a couple dives into the code, but stuff that confuses me is actually how inheritance works and why it even matters (why not just have "bottom spec", why concern yourself with the hierarchy?), and I have no idea what can be done with interceptors/extensions.

How data driven stuff works wrecks my brain...

Looking at the above code what would actually be ideal would be something like this:

abstract class Spec extends Specification {
  @Inject([Impl1Provider, Impl2Provider])
  def sut
}

Which is similar to the data driven spec proposal but probably shittier, because you cannot set/calculate multiple fields.
Is there a way to register specs to Spock programatically?

If there was it would be possible to do something like:

[sut1, sut2].forEach(sut -> Spock.register(new Spec(sut)))

Which would make things easier I think - no special annotations, just good old dependency injection.

[blazmrak]

I am not familiar with JUnit Platform, but would it be possible to have some Provider interface and during the discovery you would register specs provided by the provider and not register them when doing the "normal" scanning?

Something like this:

class Spec extends Specification implements Provider {
  private SUT sut;

  public Spec(SUT sut) {
    this.sut = sut;
  }

  @Override
  List<Specification> provide() {
    return [new Spec(new SUTImpl())]
  }
}

I think you could stretch this to pass in factories to actually work with lifecycle hooks... something like this:

class Spec extends Specification implements Provider {
  private Supplier<SUT> supplier;
  @Shared
  private SUT sut;

  public Spec(Supplier<SUT> supplier) {
    super();
    this.supplier= supplier;
  }

  public setup() {
    sut = supplier.get()
  }

  @Override
  List<Specification> provide() {
    return [new Spec(SUTImpl::new)]
  }
}

But then again, I have no idea how viable this is and how would it interact with all the magic behind JUnit and Spock :D