Scala 用于实现子类的特征测试

Question

Given a scala trait with implementing sub-classes

trait Foo {
  def doesStuff() : Int
}

case class Bar() extends Foo { ... }

case class Baz() extends Foo { ... }

How do the unit tests get organized in order to test the trait and then apply the tests to each of the implementations?

I'm looking for something of the form:

class FooSpec(foo : Foo) extends FlatSpec {
  "A Foo" should {
    "do stuff" in {
      assert(foo.doesStuff == 42)
    }
  }
}

Which would then be applied to each of the implementing classes:

FooSpec(Bar())

FooSpec(Baz())

Answer 1

If the implementations of Bar.doesStuff and Baz.doesStuff have different behavior, having two separate tests is the appropriate solution.

import org.scalatest.FlatSpec

class FooSpec1 extends FlatSpec {

  "a Bar" should "do a bar thing" in {
    Bar().doesStuff() == 42
  }

  "a Baz" should "do a baz thing" in {
    Baz().doesStuff() % 2 == 0
  }

}

However, if they have the same behavior, you can refactor the tests with a function to avoid duplicate code. I don't believe scalatest can achieve this reuse pattern at the spec level like you're asking for.

import org.scalatest.FlatSpec

class FooSpec2 extends FlatSpec {

  def checkDoesStuff(foo: Foo): Boolean =
    foo.doesStuff() == 42

  "a Bar" should "do a bar thing" in {
    checkDoesStuff(Bar())
  }

  "a Baz" should "do a baz thing" in {
    checkDoesStuff(Baz())
  }

}

Property-based testing can do exactly what you're looking for though. Here's an example using scalacheck:

import org.scalacheck.{Gen, Properties}
import org.scalacheck.Prop.forAll

object FooProperties extends Properties("Foo"){

  val fooGen: Gen[Foo] = Gen.pick(1, List(Bar(), Baz())).map(_.head)

  property("a Foo always does stuff") = forAll(fooGen){
    (foo: Foo) => foo.doesStuff() == 42
  }

}

Unlike ScalaTest specs, properties are always functions. The forAll function takes a generator, samples values of the generator and runs the test on all samples. Our generator will always return either an instance of Bar or Baz which means the property will cover all the cases you're looking to test. forAll asserts that if a single test fails the entire property fails.

Answer 2

Whilst the accepted answer definitely works, scalacheck runs 100 unit tests by default, and is typically used to tackle a different issue than the question is suggesting.

Perhaps this wasn't available in 2019, but I would like to contribute an answer that as of ScalaTest 3.2.9 (and perhaps earlier) is more applicable.

You can create a trait to house all the re-usable tests and then extend that into your unit tests. I will give a brief example below using the question classes. The full example is provided at this link under "Shared tests".

trait FooBehaviours { this: AnyFlatSpec =>
    /*
    the defined tests here should consider how your trait behaves in certain conditions
    */
    def emptyFoo(foo: => Foo): Unit = {
        it should "do stuff" in {
            assert(foo.doesStuff == 42)
        }
    }
    def fullFoo(foo: => Foo): Unit = {
        it should "do stuff" in {
            assert(foo.doesStuff == 420)
        }
    }
}

class FooSpec extends AnyFlatSpec with FooBehaviours {
    //these methods are defs but will be re-instantiated in the behaviour tests due to the call-by-name ": =>" parameters 
    def bar = Bar()
    def baz = Baz()
    
    behavior of "A bar"
    it should behave like emptyFoo(bar)
    it should behave like fullFoo(bar)
    
    behavior of "A baz"
    it should behave like emptyFoo(baz)
    it should behave like fullFoo(baz)
}

Excerpts from the link in case it doesn't work

Sometimes you may want to run the same test code on different fixture objects. In other words, you may want to write tests that are "shared" by different fixture objects. To accomplish this in a AnyFlatSpec, you first place shared tests in behavior functions. These behavior functions will be invoked during the construction phase of any AnyFlatSpec that uses them, so that the tests they contain will be registered as tests in that AnyFlatSpec. For example, given this stack class:

...

You may want to test the Stack class in different states: empty, full, with one item, with one item less than capacity, etc. You may find you have several tests that make sense any time the stack is non-empty. Thus you'd ideally want to run those same tests for three stack fixture objects: a full stack, a stack with a one item, and a stack with one item less than capacity. With shared tests, you can factor these tests out into a behavior function, into which you pass the stack fixture to use when running the tests. So in your AnyFlatSpec for stack, you'd invoke the behavior function three times, passing in each of the three stack fixtures so that the shared tests are run for all three fixtures. You can define a behavior function that encapsulates these shared tests inside the AnyFlatSpec that uses them. If they are shared between different AnyFlatSpecs, however, you could also define them in a separate trait that is mixed into each AnyFlatSpec that uses them.