The total number of tests that are expected to run when this Suite
's run
method is invoked.
The total number of tests that are expected to run when this Suite
's run
method is invoked.
a Filter
with which to filter tests to count based on their tags
An immutable IndexedSeq
of this SuiteMixin
object's nested Suite
s.
An immutable IndexedSeq
of this SuiteMixin
object's nested Suite
s. If this SuiteMixin
contains no nested Suite
s,
this method returns an empty IndexedSeq
.
The fully qualified name of the class that can be used to rerun this suite.
The fully qualified name of the class that can be used to rerun this suite.
Runs zero to many of this suite's nested suites.
Runs zero to many of this suite's nested suites.
the Args
for this run
a Status
object that indicates when all nested suites started by this method have completed, and whether or not a failure occurred.
Runs zero to many of this suite's tests.
Runs zero to many of this suite's tests.
an optional name of one test to run. If None
, all relevant tests should be run.
I.e., None
acts like a wildcard that means run all relevant tests in this Suite
.
the Args
for this run
a Status
object that indicates when all tests started by this method have completed, and whether or not a failure occurred.
This suite's style name.
This suite's style name.
This lifecycle method provides a string that is used to determine whether this suite object's style is one of the chosen styles for the project.
A Map
whose keys are String
tag names with which tests in this Suite
are marked, and
whose values are the Set
of test names marked with each tag.
A Map
whose keys are String
tag names with which tests in this Suite
are marked, and
whose values are the Set
of test names marked with each tag. If this Suite
contains no tags, this
method returns an empty Map
.
Subclasses may implement this method to define and/or discover tags in a custom manner, but overriding method implementations
should never return an empty Set
as a value. If a tag has no tests, its name should not appear as a key in the
returned Map
.
A Set
of test names.
A Set
of test names. If this Suite
contains no tests, this method returns an empty Set
.
Although subclass and subtrait implementations of this method may return a Set
whose iterator produces String
test names in a well-defined order, the contract of this method does not required a defined order. Subclasses are free to
implement this method and return test names in either a defined or undefined order.
Runs the passed test function with a fixture established by this method.
Runs the passed test function with a fixture established by this method.
This method should set up the fixture needed by the tests of the
current suite, invoke the test function, and if needed, perform any clean
up needed after the test completes. Because the NoArgTest
function
passed to this method takes no parameters, preparing the fixture will require
side effects, such as initializing an external database.
the no-arg test function to run with a fixture
Registers code to be executed after each of this suite's tests.
Registers code to be executed after each of this suite's tests.
This trait's implementation of runTest
executes the code passed to this method after running
each test. Thus the code passed to this method can be used to tear down a test fixture
needed by each test.
Registers code to be executed before each of this suite's tests.
Registers code to be executed before each of this suite's tests.
This trait's implementation
of runTest
executes the code passed to this method before running
each test. Thus the code passed to this method can be used to set up a test fixture
needed by each test.
This trait's implementation of run sets a flag indicating run has been invoked, after which
any invocation to before
or after
will complete abruptly
with a NotAllowedException
.
This trait's implementation of run sets a flag indicating run has been invoked, after which
any invocation to before
or after
will complete abruptly
with a NotAllowedException
.
an optional name of one test to run. If None
, all relevant tests should be run.
I.e., None
acts like a wildcard that means run all relevant tests in this Suite
.
the Args
for this run
a Status
object that indicates when all tests and nested suites started by this method have completed, and whether or not a failure occurred.
Run a test surrounded by calls to the code passed to before
and after
, if any.
Run a test surrounded by calls to the code passed to before
and after
, if any.
This trait's implementation of this method ("this method") invokes
the function registered with before
, if any,
before running each test and the function registered with after
, if any,
after running each test. It runs each test by invoking super.runTest
, passing along
the five parameters passed to it.
If any invocation of the function registered with before
completes abruptly with an exception, this
method will complete abruptly with the same exception. If any call to
super.runTest
completes abruptly with an exception, this method
will complete abruptly with the same exception, however, before doing so, it will
invoke the function registered with after
, if any. If the function registered with after
also completes abruptly with an exception, this
method will nevertheless complete abruptly with the exception previously thrown by super.runTest
.
If super.runTest
returns normally, but the function registered with after
completes abruptly with an
exception, this method will complete abruptly with the exception thrown by the function registered with after
.
the name of one test to run.
the Args
for this run
a Status
object that indicates when the test started by this method has completed, and whether or not it failed .
Trait that can be mixed into suites that need code executed before and after running each test.
BeforeAndAfter
when you need to perform the same side-effects before and/or after tests, rather than at the beginning or end of tests. Note: For more insight into whereBeforeAndAfter
fits into the big picture, see the Shared fixtures section in the documentation for your chosen style trait.A test fixture is composed of the objects and other artifacts (files, sockets, database connections, etc.) tests use to do their work. When multiple tests need to work with the same fixtures, it is important to try and avoid duplicating the fixture code across those tests. The more code duplication you have in your tests, the greater drag the tests will have on refactoring the actual production code. Trait
BeforeAndAfter
offers one way to eliminate such code duplication: abefore
clause that will register code to be run before each test, and anafter
clause that will register code to be run after.Here's an example:
The
before
andafter
methods can each only be called once perSuite
, and cannot be invoked afterrun
has been invoked. If either of the registered before or after functions complete abruptly with an exception, it will be reported as an aborted suite and no more tests will be attempted in that suite.Note that the only way
before
andafter
code can communicate with test code is via some side-effecting mechanism, commonly by reassigning instancevar
s or by changing the state of mutable objects held from instanceval
s (as in this example). If using instancevar
s or mutable objects held from instanceval
s you wouldn't be able to run tests in parallel in the same instance of the test class unless you synchronized access to the shared, mutable state. This is why ScalaTest'sParallelTestExecution
trait extendsOneInstancePerTest
. By running each test in its own instance of the class, each test has its own copy of the instance variables, so you don't need to synchronize. Were you to mixParallelTestExecution
into theExampleSuite
above, the tests would run in parallel just fine without any synchronization needed on the mutableStringBuilder
andListBuffer[String]
objects.Although
BeforeAndAfter
provides a minimal-boilerplate way to execute code before and after tests, it isn't designed to enable stackable traits, because the order of execution would be non-obvious. If you want to factor out before and after code that is common to multiple test suites, you should use traitBeforeAndAfterEach
instead.The advantage this trait has over
BeforeAndAfterEach
is that its syntax is more concise. The main disadvantage is that it is not stackable, whereasBeforeAndAfterEach
is. I.e., you can write several traits that extendBeforeAndAfterEach
and providebeforeEach
methods that include a call tosuper.beforeEach
, and mix them together in various combinations. By contrast, only one call to thebefore
registration function is allowed in a suite or spec that mixes inBeforeAndAfter
. In addition,BeforeAndAfterEach
allows you to access the config map and test name via theTestData
passed to itsbeforeEach
andafterEach
methods, whereasBeforeAndAfter
gives you no access to the config map.