ScalaTest 3.1.0-SNAP13 < Back

Packages

package root
Definition Classes
root
package org
Definition Classes
root
package scalatest
ScalaTest's main traits, classes, and other members, including members supporting ScalaTest's DSL for the Scala interpreter.
ScalaTest's main traits, classes, and other members, including members supporting ScalaTest's DSL for the Scala interpreter.
Definition Classes
org
package compatible
Definition Classes
scalatest
package concurrent
ScalaTest's main traits, classes, and other members, including members supporting ScalaTest's DSL for the Scala interpreter.
ScalaTest's main traits, classes, and other members, including members supporting ScalaTest's DSL for the Scala interpreter.
Definition Classes
scalatest
package enablers
Definition Classes
scalatest
package events
Definition Classes
scalatest
package exceptions
Definition Classes
scalatest
package featurespec
Definition Classes
scalatest
package fixture
Package fixture deprecated types.
Package fixture deprecated types.
Definition Classes
scalatest
AsyncConfigMapFixture
AsyncFeatureSpec
AsyncFlatSpec
AsyncFreeSpec
AsyncFunSpec
AsyncFunSuite
AsyncTestDataFixture
AsyncTestRegistration
AsyncTestSuite
AsyncWordSpec
ConfigMapFixture
FeatureSpec
FlatSpec
FreeSpec
FunSpec
FunSuite
NoArg
PropSpec
Suite
TestDataFixture
TestRegistration
TestSuite
UnitFixture
WordSpec
package flatspec
Definition Classes
scalatest
package freespec
Definition Classes
scalatest
package funspec
Definition Classes
scalatest
package funsuite
Definition Classes
scalatest
package matchers
Definition Classes
scalatest
package path
Definition Classes
scalatest
package prop
Scalatest support for Property-based testing.
Scalatest support for Property-based testing.
Introduction to Property-based Testing
In traditional unit testing, you write tests that describe precisely what the test will do: create these objects, wire them together, call these functions, assert on the results, and so on. It is clear and deterministic, but also limited, because it only covers the exact situations you think to test. In most cases, it is not feasible to test all of the possible combinations of data that might arise in real-world use.
Property-based testing works the other way around. You describe properties -- rules that you expect your classes to live by -- and describe how to test those properties. The test system then generates relatively large amounts of synthetic data (with an emphasis on edge cases that tend to make things break), so that you can see if the properties hold true in these situations.
As a result, property-based testing is scientific in the purest sense: you are stating a hypothesis about how things should work (the property), and the system is trying to falsify that hypothesis. If the tests pass, that doesn't prove the property holds, but it at least gives you some confidence that you are probably correct.
Property-based testing is deliberately a bit random: while the edge cases get tried upfront, the system also usually generates a number of random values to try out. This makes things a bit non-deterministic -- each run will be tried with somewhat different data. To make it easier to debug, and to build regression tests, the system provides tools to re-run a failed test with precisely the same data.
Background
TODO: Bill should insert a brief section on QuickCheck, ScalaCheck, etc, and how this system is similar and different.
Using Property Checks
In order to use the tools described here, you should import this package:
```
import org.scalatest._
import org.scalatest.prop._
```
This library is designed to work well with the types defined in Scalactic, and some functions take types such as PosZInt as parameters. So it can also be helpful to import those with:
```
import org.scalactic.anyvals._
```
In order to call forAll, the function that actually performs property checks, you will need to either extend or import GeneratorDrivenPropertyChecks, like this:
```
class DocExamples extends FlatSpec with Matchers with GeneratorDrivenPropertyChecks {
```
There's nothing special about FlatSpec, though -- you may use any of ScalaTest's styles with property checks. GeneratorDrivenPropertyChecks extends CommonGenerators, so it also provides access to the many utilities found there.
What Does a Property Look Like?
Let's check a simple property of Strings -- that if you concatenate a String to itself, its length will be doubled:
```
"Strings" should "have the correct length when doubled" in {
  forAll { (s: String) =>
    val s2 = s * 2
    s2.length should equal (s.length * 2)
  }
}
```
(Note that the examples here are all using the FlatSpec style, but will work the same way with any of ScalaTest's styles.)
As the name of the tests suggests, the property we are testing is the length of a String that has been doubled.
The test begins with forAll. This is usually the way you'll want to begin property checks, and that line can be read as, "For all Strings, the following should be true".
The test harness will generate a number of Strings, with various contents and lengths. For each one, we compute s * 2. (* is a function on String, which appends the String to itself as many times as you specify.) And then we check that the length of the doubled String is twice the length of the original one.
Using Specific Generators
Let's try a more general version of this test, multiplying arbitrary Strings by arbitrary multipliers:
```
"Strings" should "have the correct length when multiplied" in {
  forAll { (s: String, n: PosZInt) =>
    val s2 = s * n.value
    s2.length should equal (s.length * n.value)
  }
}
```
Again, you can read the first line of the test as "For all Strings, and all non-negative Integers, the following should be true". (PosZInt is a type defined in Scalactic, which can be any positive integer, including zero. It is appropriate to use here, since multiplying a String by a negative number doesn't make sense.)
This intuitively makes sense, but when we try to run it, we get a JVM Out of Memory error! Why? Because the test system tries to test with the "edge cases" first, and one of the more important edge cases is Int.MaxValue. It is trying to multiply a String by that, which is far larger than the memory of even a big computer, and crashing.
So we want to constrain our test to sane values of n, so that it doesn't crash. We can do this by using more specific Generators.
When we write a forAll test like the above, ScalaTest has to generate the values to be tested -- the semi-random Strings, Ints and other types that you are testing. It does this by calling on an implicit Generator for the desired type. The Generator generates values to test, starting with the edge cases and then moving on to randomly-selected values.
ScalaTest has built-in Generators for many major types, including String and PosZInt, but these Generators are generic: they will try any value, including values that can break your test, as shown above. But it also provides tools to let you be more specific.
Here is the fixed version of the above test:
```
"Strings" should "have the correct length when multiplied" in {
  forAll(strings, posZIntsBetween(0, 1000))
  { (s: String, n: PosZInt) =>
    val s2 = s * n.value
    s2.length should equal (s.length * n.value)
  }
}
```
This is using a variant of forAll, which lets you specify the Generators to use instead of just picking the implicit one. CommonGenerators.strings is the built-in Generator for Strings, the same one you were getting implicitly. (The other built-ins can be found in CommonGenerators. They are mixed into GeneratorDrivenPropertyChecks, so they are readily available.)
But CommonGenerators.posZIntsBetween is a function that creates a Generator that selects from the given values. In this case, it will create a Generator that only creates numbers from 0 to 1000 -- small enough to not blow up our computer's memory. If you try this test, this runs correctly.
The moral of the story is that, while using the built-in Generators is very convenient, and works most of the time, you should think about the data you are trying to test, and pick or create a more-specific Generator when the test calls for it.
CommonGenerators contains many functions that are helpful in common cases. In particular:
- xxsBetween (where xxs might be Int, Long, Float or most other significant numeric types) gives you a value of the desired type in the given range, as in the posZIntsBetween() example above.
- CommonGenerators.specificValue and CommonGenerators.specificValues create Generators that produce either one specific value every time, or one of several values randomly. This is useful for enumerations and types that behave like enumerations.
- CommonGenerators.evenly and CommonGenerators.frequency create higher-level Generators that call other Generators, either more or less equally or with a distribution you define.
Testing Your Own Types
Testing the built-in types isn't very interesting, though. Usually, you have your own types that you want to check the properties of. So let's build up an example piece by piece.
Say you have this simple type:
```
sealed trait Shape {
  def area: Double
}
case class Rectangle(width: Int, height: Int) extends Shape {
  require(width > 0)
  require(height > 0)
  def area: Double = width * height
}
```
Let's confirm a nice straightforward property that is surely true: that the area is greater than zero:
```
"Rectangles" should "have a positive area" in {
   forAll { (w: PosInt, h: PosInt) =>
     val rect = Rectangle(w, h)
     rect.area should be > 0.0
   }
 }
```
Note that, even though our class takes ordinary Ints as parameters (and checks the values at runtime), it is actually easier to generate the legal values using Scalactic's PosInt type.
This should work, right? Actually, it doesn't -- if we run it a few times, we quickly hit an error!
```
[info] Rectangles
[info] - should have a positive area *** FAILED ***
[info]   GeneratorDrivenPropertyCheckFailedException was thrown during property evaluation.
[info]    (DocExamples.scala:42)
[info]     Falsified after 2 successful property evaluations.
[info]     Location: (DocExamples.scala:42)
[info]     Occurred when passed generated values (
[info]       None = PosInt(399455539),
[info]       None = PosInt(703518968)
[info]     )
[info]     Init Seed: 1568878346200
```
TODO: fix the above error to reflect the better errors we should get when we merge in the code being forward-ported from 3.0.5.
Looking at it, we can see that the numbers being used are pretty large. What happens when we multiply them together?
```
scala> 399455539 * 703518968
res0: Int = -2046258840
```
We're hitting an Int overflow problem here: the numbers are too big to multiply together and still get an Int. So we have to fix our area function:
```
case class Rectangle(width: Int, height: Int) extends Shape {
  require(width > 0)
  require(height > 0)
  def area: Double = width.toLong * height.toLong
}
```
Now, when we run our property check, it consistently passes. Excellent -- we've caught a bug, because ScalaTest tried sufficiently large numbers.
Composing Your Own Generators
Doing things as shown above works, but having to generate the parameters and construct a Rectangle every time is a nuisance. What we really want is to create our own Generator that just hands us Rectangles, the same way we can do for PosInt. Fortunately, this is easy.
Generators can be composed in for comprehensions. So we can create our own Generator for Rectangle like this:
```
implicit val rectGenerator = for {
  w <- posInts
  h <- posInts
}
  yield Rectangle(w, h)
```
Taking that line by line:
```
w <- posInts
```
CommonGenerators.posInts is the built-in Generator for positive Ints. So this line puts a randomly-generated positive Int in w, and
```
h <- posInts
```
this line puts another one in h. Finally, this line:
```
yield Rectangle(w, h)
```
combines w and h to make a Rectangle.
That's pretty much all you need in order to build any normal case class -- just build it out of the Generators for the type of each field. (And if the fields are complex data structures themselves, build Generators for them the same way, until you are just using primitives.)
Now, our property check becomes simpler:
```
"Generated Rectangles" should "have a positive area" in {
   forAll { (rect: Rectangle) =>
     rect.area should be > 0.0
   }
 }
```
That's about as close to plain English as we can reasonably hope for!
Filtering Values with whenever()
Sometimes, not all of your generated values make sense for the property you want to check -- you know (via external information) that some of these values will never come up. In cases like this, you can create a custom Generator that only creates the values you do want, but it's often easier to just use Whenever.whenever. (Whenever is mixed into GeneratorDrivenPropertyChecks, so this is available when you need it.)
The Whenever.whenever function can be used inside of GeneratorDrivenPropertyChecks.forAll. It says that only the filtered values should be used, and anything else should be discarded. For example, look at this property:
```
"Fractions" should "get smaller when squared" in {
  forAll { (n: Float) =>
    whenever(n > 0 && n < 1) {
      (n * n) should be < n
    }
  }
}
```
We are testing a property of numbers less than 1, so we filter away everything that is not the numbers we want. This property check succeeds, because we've screened out the values that would make it fail.
Discard Limits
You shouldn't push Whenever.whenever too far, though. This system is all about trying random data, but if too much of the random data simply isn't usable, you can't get valid answers, and the system tracks that.
For example, consider this apparently-reasonable test:
```
"Space Chars" should "not also be letters" in {
  forAll { (c: Char) =>
    whenever (c.isSpaceChar) {
      assert(!c.isLetter)
    }
  }
}
```
Although the property is true, this test will fail with an error like this:
```
[info] Lowercase Chars
[info] - should upper-case correctly *** FAILED ***
[info]   Gave up after 0 successful property evaluations. 49 evaluations were discarded.
[info]   Init Seed: 1568855247784
```
Because the vast majority of Chars are not spaces, nearly all of the generated values are being discarded. As a result, the system gives up after a while. In cases like this, you usually should write a custom Generator instead.
The proportion of how many discards to permit, relative to the number of successful checks, is configuration-controllable. See GeneratorDrivenPropertyChecks for more details.
Randomization
The point of Generator is to create pseudo-random values for checking properties. But it turns out to be very inconvenient if those values are actually random -- that would mean that, when a property check fails occasionally, you have no good way to invoke that specific set of circumstances again for debugging. We want "randomness", but we also want it to be deterministic, and reproducible when you need it.
To support this, all "randomness" in ScalaTest's property checking system uses the Randomizer class. You start by creating a Randomizer using an initial seed value, and call that to get your "random" value. Each call to a Randomizer function returns a new Randomizer, which you should use to fetch the next value.
GeneratorDrivenPropertyChecks.forAll uses Randomizer under the hood: each time you run a forAll-based test, it will automatically create a new Randomizer, which by default is seeded based on the current system time. You can override this, as discussed below.
Since Randomizer is actually deterministic (the "random" values are unobvious, but will always be the same given the same initial seed), this means that re-running a test with the same seed will produce the same values.
If you need random data for your own Generators and property checks, you should use Randomizer in the same way; that way, your tests will also be re-runnable, when needed for debugging.
Debugging, and Re-running a Failed Property Check
In Testing Your Own Types above, we found to our surprise that the property check failed with this error:
```
[info] Rectangles
[info] - should have a positive area *** FAILED ***
[info]   GeneratorDrivenPropertyCheckFailedException was thrown during property evaluation.
[info]    (DocExamples.scala:42)
[info]     Falsified after 2 successful property evaluations.
[info]     Location: (DocExamples.scala:42)
[info]     Occurred when passed generated values (
[info]       None = PosInt(399455539),
[info]       None = PosInt(703518968)
[info]     )
[info]     Init Seed: 1568878346200
```
There must be a bug here -- but once we've fixed it, how can we make sure that we are re-testing exactly the same case that failed?
This is where the pseudo-random nature of Randomizer comes in, and why it is so important to use it consistently. So long as all of our "random" data comes from that, then all we need to do is re-run with the same seed.
That's why the Init Seed shown in the message above is crucial. We can re-use that seed -- and therefore get exactly the same "random" data -- by using the -S flag to ScalaTest.
So you can run this command in sbt to re-run exactly the same property check:
```
testOnly *DocExamples -- -z "have a positive area" -S 1568878346200
```
Taking that apart:
- testOnly *DocExamples says that we only want to run suites whose paths end with DocExamples
- -z "have a positive area" says to only run tests whose names include that string.
- -S 1568878346200 says to run all tests with a "random" seed of 1568878346200
By combining these flags, you can re-run exactly the property check you need, with the right random seed to make sure you are re-creating the failed test. You should get exactly the same failure over and over until you fix the bug, and then you can confirm your fix with confidence.
Configuration
In general, forAll() works well out of the box. But you can tune several configuration parameters when needed. See GeneratorDrivenPropertyChecks for info on how to set configuration parameters for your test.
Table-Driven Properties
Sometimes, you want something in between traditional hard-coded unit tests and Generator-driven, randomized tests. Instead, you sometimes want to check your properties against a specific set of inputs.
(This is particularly useful for regression tests, when you have found certain inputs that have caused problems in the past, and want to make sure that they get consistently re-tested.)
ScalaTest supports these, by mixing in TableDrivenPropertyChecks. See the documentation for that class for the full details.
Definition Classes
scalatest
package propspec
Definition Classes
scalatest
package tagobjects
Definition Classes
scalatest
package time
Definition Classes
scalatest
package tools
Definition Classes
scalatest
package words
Definition Classes
scalatest
package wordspec
Definition Classes
scalatest

org.scalatest

fixture

package fixture

Package fixture deprecated types.

Source: package.scala

Linear Supertypes

AnyRef, Any

Type Members

trait AsyncConfigMapFixture extends AnyRef

Trait that when mixed into a fixture.AsyncTestSuite passes the config map passed to runTest as a fixture into each test.

Here's an example in which tests just check to make sure "hello" and "world" are defined keys in the config map:

package org.scalatest.examples.fixture.configmapfixture

import org.scalatest._

class ExampleAsyncSpec extends fixture.AsyncFlatSpec with fixture.AsyncConfigMapFixture with Matchers {

  "The config map" should "contain hello" in { configMap =>
    // Use the configMap passed to runTest in the test
    configMap should contain key "hello"
  }

  it should "contain world" in { configMap =>
    configMap should contain key "world"
  }
}

If you run this class without defining "hello" and "world" in the confg map, the tests will fail:

scala> org.scalatest.run(new ExampleSpec)
ExampleSpec:
The config map
- should contain hello *** FAILED ***
  Map() did not contain key "hello" (:20)
- should contain world *** FAILED ***
  Map() did not contain key "world" (:24)

If you do define "hello" and "world" keys in the confg map, the tests will success:

scala> org.scalatest.run(new ExampleSpec, configMap = Map("hello" -> "hi", "world" -> "globe"))
ExampleSpec:
The config map
- should contain hello
- should contain world

trait AsyncTestDataFixture extends AnyRef

Trait that when mixed into a fixture.AsyncTestSuite passes the TestData passed to withFixture as a fixture into each test.

For example, here's how you could access the test's name in each test using AsyncTestDataFixture:

package org.scalatest.examples.fixture.testdatafixture

import org.scalatest._

class ExampleAsyncSpec extends fixture.AsyncFlatSpec with fixture.AsyncTestDataFixture {

  "Accessing the test data" should "be easy!" in { td =>
    assert(td.name == "Accessing the test data should be easy!")
  }

  it should "be fun!" in { td =>
    assert(td.name == "Accessing the test data should be fun!")
  }
}

trait AsyncTestRegistration extends AnyRef
Trait declaring methods that can be used to register test functions that accept a fixture parameter and have result type Future[Assertion].
trait AsyncTestSuite extends Suite with scalatest.AsyncTestSuite
The base trait of ScalaTest's "fixture" async testing styles, which enable you to pass fixture objects into tests.
The base trait of ScalaTest's "fixture" async testing styles, which enable you to pass fixture objects into tests.
This trait provides a final override of withFixture(OneArgTest), declared in supertrait fixture.Suite, because the withFixture(OneArgTest) lifecycle method assumes synchronous testing. Here is its signature:
```
def withFixture(test: OneArgTest): Outcome
```
The test function interface, OneArgTest, offers an apply method that takes a FixtureParam and returns Outcome:
```
// In trait OneArgTest:
def apply(fixture: FixtureParam): Outcome
```
Because the result of a test is an Outcome, when the test function returns, the test body must have determined an outcome already. It will already be one of Succeeded, Failed, Canceled, or Pending. This is also true when withFixture(OneArgTest) returns: because the result type of withFixture(OneArgTest) is Outcome, the test body has by definition has already finished execution.
This trait overrides and makes abstract the runTest method. Subtraits must must implement this method to call withFixture(OneArgAsyncTest) instead of withFixture(OneArgTest), where withFixture(OneArgAsyncTest) is a new method declared in this trait with the following signature and implementation:
```
def withFixture(test: OneArgAsyncTest): FutureOutcome = {
  test()
}
```
Instead of returning Outcome like withFixture, the withFixture method returns a FutureOutcome. Similarly, the apply method of test function interface, OneArgAsyncTest, returns FutureOutcome:
```
// In trait OneArgAsyncTest:
def apply(fixture: FixtureParam): FutureOutcome
```
The withFixture method supports async testing, because when the test function returns, the test body has not necessarily finished execution.
The recommended way to ensure cleanup is performed after a test body finishes execution is to use the complete-lastly syntax, defined in supertrait org.scalatest.CompleteLastly, which will ensure that cleanup will occur whether future-producing code completes abruptly by throwing an exception, or returns normally yielding a future. In the latter case, complete-lastly will register the cleanup code to execute asynchronously when the future completes.
To enable the stacking of traits that define withFixture(NoArgAsyncTest), it is a good idea to let withFixture(NoArgAsyncTest) invoke the test function instead of invoking the test function directly. To do so, you'll need to convert the OneArgAsyncTest to a NoArgAsyncTest. You can do that by passing the fixture object to the toNoArgAsyncTest method of OneArgAsyncTest. In other words, instead of writing “test(theFixture)”, you'd delegate responsibility for invoking the test function to the withFixture(NoArgAsyncTest) method of the same instance by writing:
```
withFixture(test.toNoArgAsyncTest(theFixture))
```
Thus, the recommended structure of a withFixture implementation that performs cleanup looks like this:
```
// Your implementation
override def withFixture(test: OneArgAsyncTest) = {

  // Perform setup here
  val theFixture = ...

  complete {
    withFixture(test.toNoArgAsyncTest(theFixture)) // Invoke the test function
  } lastly {
    // Perform cleanup here
  }
}
```
If you have no cleanup to perform, you can write withFixture like this instead:
```
// Your implementation
override def withFixture(test: OneArgAsyncTest) = {

  // Perform setup here
  val theFixture = ...

  withFixture(test.toNoArgAsyncTest(theFixture)) // Invoke the test function
}
```
If you want to perform an action only for certain outcomes, you'll need to register code performing that action as a callback on the Future using one of Future registration methods: onComplete, onSuccess, or onFailure. Note that if a test fails, that will be treated as a scala.util.Success(org.scalatest.Failure). So if you want to perform an action if a test fails, for example, you'd register the callaback using onSuccess, like this:
```
// Your implementation
override def withFixture(test: OneArgAsyncTest) = {

  // Perform setup here
  val theFixture = ...

  val futureOutcome =
      withFixture(test.toNoArgAsyncTest(theFixture)) // Invoke the test function

  futureOutcome onFailedThen { _ =>
    // perform action that you want to occur
    // only if a test fails here
  }
}
```
Lastly, if you want to transform the outcome in some way in withFixture, you'll need to use either the map or transform methods of Future, like this:
```
// Your implementation
override def withFixture(test: OneArgAsyncTest) = {

  // Perform setup here
  val theFixture = ...

  val futureOutcome =
      withFixture(test.toNoArgAsyncTest(theFixture)) // Invoke the test function

  futureOutcome change { outcome =>
    // transform the outcome into a new outcome here
  }
}
```
Note that a NoArgAsyncTest's apply method will only return a Failure if the test completes abruptly with an exception (such as OutOfMemoryError) that should cause the suite to abort rather than the test to fail. Thus usually you would use map to transform future outcomes, not transform, so that such suite-aborting exceptions pass through unchanged. The suite will abort asynchronously with any exception returned in a Failure.

trait ConfigMapFixture extends AnyRef

Trait that when mixed into a fixture.Suite passes the config map passed to runTest as a fixture into each test.

Here's an example in which tests just check to make sure "hello" and "world" are defined keys in the config map:

package org.scalatest.examples.fixture.configmapfixture

import org.scalatest._

class ExampleSpec extends fixture.FlatSpec with fixture.ConfigMapFixture with Matchers {

  "The config map" should "contain hello" in { configMap =>
    // Use the configMap passed to runTest in the test
    configMap should contain key "hello"
  }

  it should "contain world" in { configMap =>
    configMap should contain key "world"
  }
}

If you run this class without defining "hello" and "world" in the confg map, the tests will fail:

scala> org.scalatest.run(new ExampleSpec)
ExampleSpec:
The config map
- should contain hello *** FAILED ***
  Map() did not contain key "hello" (:20)
- should contain world *** FAILED ***
  Map() did not contain key "world" (:24)

If you do define "hello" and "world" keys in the confg map, the tests will success:

scala> org.scalatest.run(new ExampleSpec, configMap = Map("hello" -> "hi", "world" -> "globe"))
ExampleSpec:
The config map
- should contain hello
- should contain world

trait NoArg extends DelayedInit with () => Unit
A function that takes no parameters (i.e., a Function0 or "no-arg" function) and results in Unit, which when invoked executes the body of the constructor of the class into which this trait is mixed.
A function that takes no parameters (i.e., a Function0 or "no-arg" function) and results in Unit, which when invoked executes the body of the constructor of the class into which this trait is mixed.
This trait extends DelayedInit and defines a delayedInit method that saves the body of the constructor (passed to delayedInit) for later execution when apply is invoked.
This trait is somewhat magical and therefore may be challenging for your collegues to understand, so please use it as a last resort only when the simpler options described in the "shared fixtures" section of your chosen style trait won't do the job. NoArg is intended to address a specific use case that will likely be rare, and is unlikely to be useful outside of its intended use case, but it is quite handy for its intended use case (described in the next paragraph). One potential gotcha, for example, is that a subclass's constructor body could in theory be executed multiple times by simply invoking apply multiple times. In the intended use case for this trait, however, the body will be executed only once.
The intended use case for this method is (relatively rare) situations in which you want to extend a different instance of the same class for each test, with the body of the test inheriting the members of that class, and with code executed before and/or after the body of the test.
For example, Akka's TestKit class takes an ActorSystem, which must have a unique name. To run a suite of tests in parallel, each test must get its own ActorSystem, to ensure the tests run in isolation. At the end of each test, the ActorSystem must be shutdown. With NoArg, you can achieve this by first defining a class that extends TestKit and mixes in NoArg. Here's an example taken with permission from the book Akka Concurrency, by Derek Wyatt:
```
import akka.actor.ActorSystem
import akka.testkit.{TestKit, ImplicitSender}
import java.util.concurrent.atomic.AtomicInteger
import org.scalatest.fixture.NoArg

object ActorSys {
  val uniqueId = new AtomicInteger(0)
}

class ActorSys(name: String) extends
        TestKit(ActorSystem(name))
        with ImplicitSender
        with NoArg {

  def this() = this(
    "TestSystem%05d".format(
       ActorSys.uniqueId.getAndIncrement()))

  def shutdown(): Unit = system.shutdown()

  override def apply() {
    try super.apply()
    finally shutdown()
  }
}
```
Given this implementation of ActorSys, which will invoke shutdown after the constructor code is executed, you can run each test in a suite in a subclass of TestKit, giving each test's TestKit an ActorSystem with a unique name, allowing you to safely run those tests in parallel. Here's an example from Akka Concurrency:
```
class MyActorSpec extends fixture.WordSpec
        with Matchers
        with UnitFixture
        with ParallelTestExecution {

  def makeActor(): ActorRef =
    system.actorOf(Props[MyActor], "MyActor")

  "My Actor" should {
    "throw when made with the wrong name" in new ActorSys {
      an [Exception] should be thrownBy {
        // use a generated name
        val a = system.actorOf(Props[MyActor])
      }
    }
    "construct without exception" in new ActorSys {
      val a = makeActor()
      // The throw will cause the test to fail
    }
    "respond with a Pong to a Ping" in new ActorSys {
      val a = makeActor()
      a ! Ping
      expectMsg(Pong)
    }
  }
}
```
UnitFixture is used in this example, because in this case, the fixture.WordSpec feature enabling tests to be defined as functions from fixture objects of type FixtureParam to Unit is not being used. Rather, only the secondary feature that enables tests to be defined as functions from no parameters to Unit is being used. This secondary feature is described in the second-to-last paragraph on the main Scaladoc documentation of fixture.WordSpec, which says:
If a test doesn't need the fixture, you can indicate that by providing a no-arg instead of a one-arg function, ... In other words, instead of starting your function literal with something like “db =>”, you'd start it with “() =>”. For such tests, runTest will not invoke withFixture(OneArgTest). It will instead directly invoke withFixture(NoArgTest).
Since FixtureParam is unused in this use case, it could be anything. Making it Unit will hopefully help readers more easily recognize that it is not being used.
Note: As of Scala 2.11, DelayedInit (which is used by NoArg) has been deprecated, to indicate it is buggy and should be avoided if possible. Those in charge of the Scala compiler and standard library have promised that DelayedInit will not be removed from Scala unless an alternate way to achieve the same goal is provided. Thus it should be safe to use NoArg, but if you'd rather not you can achieve the same effect with a bit more boilerplate by extending (() => Unit) instead of NoArg and placing your code in an explicit body method. Here's an example:
```
import akka.actor.ActorSystem
import akka.testkit.{TestKit, ImplicitSender}
import java.util.concurrent.atomic.AtomicInteger
import org.scalatest.fixture.NoArg

object ActorSys {
  val uniqueId = new AtomicInteger(0)
}

class ActorSys(name: String) extends
        TestKit(ActorSystem(name))
        with ImplicitSender
        with (() => Unit) {

  def this() = this(
    "TestSystem%05d".format(
       ActorSys.uniqueId.getAndIncrement()))

  def shutdown(): Unit = system.shutdown()
  def body(): Unit

  override def apply() = {
    try body()
    finally shutdown()
  }
}
```
Using this version of ActorSys will require an explicit body method in the tests:
```
class MyActorSpec extends fixture.WordSpec
        with Matchers
        with UnitFixture
        with ParallelTestExecution {

  def makeActor(): ActorRef =
    system.actorOf(Props[MyActor], "MyActor")

  "My Actor" should {
    "throw when made with the wrong name" in new ActorSys {
      def body() =
        an [Exception] should be thrownBy {
          // use a generated name
          val a = system.actorOf(Props[MyActor])
        }
    }
    "construct without exception" in new ActorSys {
      def body() = {
        val a = makeActor()
        // The throw will cause the test to fail
      }
    }
    "respond with a Pong to a Ping" in new ActorSys {
      def body() = {
        val a = makeActor()
        a ! Ping
        expectMsg(Pong)
      }
    }
  }
}
```
trait Suite extends scalatest.Suite
Base trait for a family of style traits that can pass a fixture object into tests.

trait TestDataFixture extends AnyRef

Trait that when mixed into a fixture.Suite passes the TestData passed to withFixture as a fixture into each test.

For example, here's how you could access the test's name in each test using TestDataFixture:

package org.scalatest.examples.fixture.testdatafixture

import org.scalatest._

class ExampleSpec extends fixture.FlatSpec with fixture.TestDataFixture {

  "Accessing the test data" should "be easy!" in { td =>
    assert(td.name == "Accessing the test data should be easy!")
  }

  it should "be fun!" in { td =>
    assert(td.name == "Accessing the test data should be fun!")
  }
}

trait TestRegistration extends AnyRef
Trait declaring methods that can be used to register test functions that accept a fixture parameter and have any result type.
trait TestSuite extends Suite with scalatest.TestSuite
trait UnitFixture extends AnyRef
Trait that when mixed into a fixture.Suite passes the unit value as a fixture into each test.
Trait that when mixed into a fixture.Suite passes the unit value as a fixture into each test.
Since a unit value is unlikely to be of much use to a test, this trait is useful when the unit value fixture is actually never passed into any tests. Instead each test in the fixture.Suite is defined as a no-arg function; no tests are defined as one-arg functions. This should be quite rare, but occasionally can be useful. For an example, see the main documentation for trait NoArg.

Deprecated Type Members

abstract class AsyncFeatureSpec extends AsyncFeatureSpecLike
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.funsuite.FixtureAsyncFunSuite instead.
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.funsuite.FixtureAsyncFunSuite instead.
Annotations
@deprecated
Deprecated
Please use org.scalatest.featurespec.FixtureAsyncFeatureSpec instead
type AsyncFeatureSpecLike = FixtureAsyncFeatureSpecLike
Annotations
@deprecated
Deprecated
Please use org.scalatest.featurespec.FixtureAsyncFeatureSpecLike instead
abstract class AsyncFlatSpec extends AsyncFlatSpecLike
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.flatspec.FixtureAsyncFlatSpec instead.
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.flatspec.FixtureAsyncFlatSpec instead.
Annotations
@deprecated
Deprecated
Please use org.scalatest.flatspec.FixtureAsyncFlatSpec instead
type AsyncFlatSpecLike = FixtureAsyncFlatSpecLike
Annotations
@deprecated
Deprecated
Please use org.scalatest.flatspec.FixtureAsyncFlatSpecLike instead
abstract class AsyncFreeSpec extends AsyncFreeSpecLike
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.freespec.FixtureAsyncFreeSpec instead.
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.freespec.FixtureAsyncFreeSpec instead.
Annotations
@deprecated
Deprecated
Please use org.scalatest.freespec.FixtureAsyncFreeSpec instead
type AsyncFreeSpecLike = FixtureAsyncFreeSpecLike
Annotations
@deprecated
Deprecated
Please use org.scalatest.freespec.FixtureAsyncFreeSpecLike instead
abstract class AsyncFunSpec extends AsyncFunSpecLike
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.funspec.FixtureAsyncFunSpec instead.
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.funspec.FixtureAsyncFunSpec instead.
Annotations
@deprecated
Deprecated
Please use org.scalatest.funspec.FixtureAsyncFunSpec instead
type AsyncFunSpecLike = FixtureAsyncFunSpecLike
Annotations
@deprecated
Deprecated
Please use org.scalatest.funspec.FixtureAsyncFunSpecLike instead
abstract class AsyncFunSuite extends FixtureAsyncFunSuiteLike
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.funsuite.FixtureAsyncFunSuite instead.
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.funsuite.FixtureAsyncFunSuite instead.
Annotations
@deprecated
Deprecated
Please use org.scalatest.funsuite.FixtureAsyncFunSuite instead
type AsyncFunSuiteLike = FixtureAsyncFunSuiteLike
Annotations
@deprecated
Deprecated
Please use org.scalatest.funsuite.FixtureAsyncFunSuiteLike instead
abstract class AsyncWordSpec extends AsyncWordSpecLike
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.wordspec.FixtureAsyncWordSpec instead.
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.wordspec.FixtureAsyncWordSpec instead.
Annotations
@deprecated
Deprecated
Please use org.scalatest.wordspec.FixtureAsyncWordSpec instead
type AsyncWordSpecLike = FixtureAsyncWordSpecLike
Annotations
@deprecated
Deprecated
Please use org.scalatest.wordspec.FixtureAsyncWordSpecLike instead
abstract class FeatureSpec extends FeatureSpecLike
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.funsuite.FixtureAnyFunSuite instead.
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.funsuite.FixtureAnyFunSuite instead.
Annotations
@Finders() @deprecated
Deprecated
Please use org.scalatest.featurespec.FixtureAnyFeatureSpec instead
type FeatureSpecLike = FixtureAnyFeatureSpecLike
Annotations
@deprecated
Deprecated
Please use org.scalatest.featurespec.FixtureAnyFeatureSpec instead
abstract class FlatSpec extends FlatSpecLike
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.flatspec.FixtureAnyFlatSpec instead.
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.flatspec.FixtureAnyFlatSpec instead.
Annotations
@Finders() @deprecated
Deprecated
Please use org.scalatest.flatspec.FixtureAnyFlatSpec instead
type FlatSpecLike = FixtureAnyFlatSpec
Annotations
@deprecated
Deprecated
Please use org.scalatest.flatspec.FixtureAnyFlatSpec instead
abstract class FreeSpec extends FreeSpecLike
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.freespec.FixtureAnyFreeSpec instead.
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.freespec.FixtureAnyFreeSpec instead.
Annotations
@Finders() @deprecated
Deprecated
Please use org.scalatest.freespec.FixtureAnyFreeSpec instead
type FreeSpecLike = FixtureAnyFreeSpec
Annotations
@deprecated
Deprecated
Please use org.scalatest.freespec.FixtureAnyFreeSpec instead
abstract class FunSpec extends FunSpecLike
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.funspec.FixtureAnyFunSpec instead.
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.funspec.FixtureAnyFunSpec instead.
Annotations
@Finders() @deprecated
Deprecated
Please use org.scalatest.funspec.FixtureAnyFunSpec instead
type FunSpecLike = FixtureAnyFunSpec
Annotations
@deprecated
Deprecated
Please use org.scalatest.funsuite.FixtureAnyFunSpec instead
abstract class FunSuite extends FunSuiteLike
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.funsuite.FixtureAnyFunSuite instead.
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.funsuite.FixtureAnyFunSuite instead.
Annotations
@Finders() @deprecated
Deprecated
Please use org.scalatest.funsuite.FixtureAnyFunSuite instead
type FunSuiteLike = FixtureAnyFunSuiteLike
Annotations
@deprecated
Deprecated
Please use org.scalatest.funsuite.FixtureAnyFunSuite instead
abstract class PropSpec extends PropSpecLike
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.funsuite.FixtureAnyFunSuite instead.
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.funsuite.FixtureAnyFunSuite instead.
Annotations
@Finders() @deprecated
Deprecated
Please use org.scalatest.propspec.FixtureAnyPropSpec instead
type PropSpecLike = FixtureAnyPropSpec
Annotations
@deprecated
Deprecated
Please use org.scalatest.propspec.FixtureAnyPropSpec instead
abstract class WordSpec extends WordSpecLike
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.wordspec.FixtureAnyWordSpec instead.
This class is deprecated and will be removed in future version of ScalaTest, please use org.scalatest.wordspec.FixtureAnyWordSpec instead.
Annotations
@Finders() @deprecated
Deprecated
Please use org.scalatest.wordspec.FixtureAnyWordSpec instead
type WordSpecLike = FixtureAnyWordSpec
Annotations
@deprecated
Deprecated
Please use org.scalatest.wordspec.FixtureAnyWordSpec instead

Packages

Introduction to Property-based Testing

Background

Using Property Checks

What Does a Property Look Like?

Using Specific Generators

Testing Your Own Types

Composing Your Own Generators

Filtering Values with whenever()

Discard Limits

Randomization

Debugging, and Re-running a Failed Property Check

Configuration

Table-Driven Properties

fixture

package fixture

Type Members

Deprecated Type Members

Inherited from AnyRef

Inherited from Any

Ungrouped

Packages

Introduction to Property-based Testing

Background

Using Property Checks

What Does a Property Look Like?

Using Specific Generators

Testing Your Own Types

Composing Your Own Generators

Filtering Values with whenever()

Discard Limits

Randomization

Debugging, and Re-running a Failed Property Check

Configuration

Table-Driven Properties

fixture

package fixture

Type Members

Deprecated Type Members

Inherited from AnyRef

Inherited from Any

Ungrouped

fixture