Trait that when mixed into a FixtureAsyncTestSuite
passes
the config map passed to runTest
as a fixture into each test.
Trait that when mixed into a FixtureAsyncTestSuite
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 that when mixed into a FixtureAsyncTestSuite
passes the
TestData
passed to withFixture
as a fixture into each test.
Trait that when mixed into a FixtureAsyncTestSuite
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 that when mixed into a FixtureSuite
passes
the config map passed to runTest
as a fixture into each test.
Trait that when mixed into a FixtureSuite
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
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 invokewithFixture(OneArgTest)
. It will instead directly invokewithFixture(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 that when mixed into a FixtureSuite
passes the
TestData
passed to withFixture
as a fixture into each test.
Trait that when mixed into a FixtureSuite
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 that when mixed into a FixtureSuite
passes
the unit value as a fixture into each test.
Trait that when mixed into a FixtureSuite
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 FixtureSuite
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
.
Classes and traits supporting ScalaTest's "fixture" style traits, which allow you to pass fixture objects into tests.
This package is released as part of the
scalatest-core
module.