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 Suites.
An immutable IndexedSeq of this SuiteMixin object's nested Suites. If this SuiteMixin contains no nested Suites,
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 this suite of tests.
Runs this suite of tests.
an optional name of one test to execute. If None, all relevant tests should be executed.
I.e., None acts like a wildcard that means execute 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.
if any passed parameter is null.
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.
if args is null.
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.
if either testName or args is null.
A string ID for this Suite that is intended to be unique among all suites reported during a run.
A string ID for this Suite that is intended to be unique among all suites reported during a run.
The suite ID is intended to be unique, because ScalaTest does not enforce that it is unique. If it is not unique, then you may not be able to uniquely identify a particular test of a particular suite. This ability is used, for example, to dynamically tag tests as having failed in the previous run when rerunning only failed tests.
this Suite object's ID.
A user-friendly suite name for this Suite.
A user-friendly suite name for this Suite.
This trait's
implementation of this method returns the simple name of this object's class. This
trait's implementation of runNestedSuites calls this method to obtain a
name for Reports to pass to the suiteStarting, suiteCompleted,
and suiteAborted methods of the Reporter.
this Suite object's suite name.
A Map whose keys are String names of tagged tests and
whose associated values are the Set of tag names for the test.
A Map whose keys are String names of tagged tests and
whose associated values are the Set of tag names for the test. If a test has no associated tags, its name
does not appear as a key in the returned Map. If this Suite contains no tests with tags, this
method returns an empty Map.
Subclasses may override 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 test has no tags, its name should not appear as a key in the
returned Map.
Provides a TestData instance for the passed test name, given the passed config map.
Provides a TestData instance for the passed test name, given the passed config map.
This method is used to obtain a TestData instance to pass to withFixture(NoArgTest)
and withFixture(OneArgTest) and the beforeEach and afterEach methods
of trait BeforeAndAfterEach.
the name of the test for which to return a TestData instance
the config map to include in the returned TestData
a TestData instance for the specified test, which includes the specified config 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.
The styleName lifecycle method has been deprecated and will be removed in a future version of ScalaTest.
The styleName lifecycle method has been deprecated and will be removed in a future version of ScalaTest.
This method was used to support the chosen styles feature, which was deactivated in 3.1.0. The internal modularization of ScalaTest in 3.2.0
will replace chosen styles as the tool to encourage consistency across a project. We do not plan a replacement for styleName.
(Since version 3.1.0) The styleName lifecycle method has been deprecated and will be removed in a future version of ScalaTest with no replacement.
Defines a method (that takes a TestData) to be run after each
of this suite's tests.
Defines a method (that takes a TestData) to be run after each
of this suite's tests.
This trait's implementation of runTest invokes this method (passing in a
TestData containing the configMap passed to it) after invoking
super.runTest. Thus this method can be used to tear down a test fixture
needed by each test, after each test completes execution.
This trait's implementation of this method does nothing.
Defines a method (that takes a TestData) to be run before each
of this suite's tests.
Defines a method (that takes a TestData) to be run before each
of this suite's tests.
This trait's implementation of runTest invokes this method (passing in a
TestData containing the configMap passed to it) before
invoking super.runTest. Thus this method can be used to set up a test
fixture needed by each test, before each test begins execution.
This trait's implementation of this method does nothing.
Run a test surrounded by calls to beforeEach(TestData) and
afterEach(TestData).
Run a test surrounded by calls to beforeEach(TestData) and
afterEach(TestData).
This trait's implementation of this method ("this method") invokes
beforeEach(TestData)
before running each test and afterEach(TestData)
after running each test. It runs each test by invoking super.runTest, passing along
the two parameters passed to it.
If any invocation of beforeEach(TestData) completes abruptly with an exception, this
method will complete abruptly with the same exception, however, before doing so, it will
invoke afterEach(TestData).
If beforeEach(TestData) returns normally, but the subsequent 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 afterEach(TestData).
If afterEach(TestData) completes abruptly with an exception, this
method will nevertheless complete abruptly with an exception previously thrown by either
beforeEach(TestData) or super.runTest.
If both beforeEach(TestData) and super.runTest return normally, but
afterEach(TestData) completes abruptly with an exception, this method will complete
abruptly with the exception thrown by afterEach(TestData).
The reason this method invokes afterEach(TestData) even if beforeEach(TestData) or
super.runTest throws an exception is to reduce the chance that a resource
acquired by beforeEach(TestData) or super.runTest prior to completing
abruptly with the exception is not cleaned up and therefore leaked.
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 .
Stackable trait that can be mixed into suites that need code that makes use of test data (test name, tags, config map, etc.) executed before and/or after running each test.
BeforeAndAfterEachTestDatawhen you want to stack traits that perform side-effects before and/or after tests, rather than at the beginning or end of tests, when you need access to any test data (such as the config map) in the before and/or after code. Note: For more insight into whereBeforeAndAfterEachTestDatafits 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
BeforeAndAfterEachTestDataoffers one way to eliminate such code duplication: abeforeEach(TestData)method that will be run before each test (like JUnit'ssetUp), and anafterEach(TestData)method that will be run after (like JUnit'stearDown).Here's an example:
package org.scalatest.examples.flatspec.composingbeforeandaftereachtestdata import org.scalatest._ import collection.mutable.ListBuffer trait Builder extends BeforeAndAfterEachTestData { this: Suite => val builder = new StringBuilder override def beforeEach(td: TestData) { builder.append(td.name) super.beforeEach(td) // To be stackable, must call super.beforeEach(TestData) } override def afterEach(td: TestData) { try { super.afterEach(td) // To be stackable, must call super.afterEach(TestData) } finally { builder.clear() } } } trait Buffer extends BeforeAndAfterEachTestData { this: Suite => val buffer = new ListBuffer[String] override def afterEach(td: TestData) { try { super.afterEach(td) // To be stackable, must call super.afterEach(TestData) } finally { buffer.clear() } } } class ExampleSpec extends FlatSpec with Builder with Buffer { "Testing" should "be easy" in { builder.append("!") assert(builder.toString === "Testing should be easy!") assert(buffer.isEmpty) buffer += "sweet" } it should "be fun" in { builder.append("!") assert(builder.toString === "Testing should be fun!") assert(buffer.isEmpty) buffer += "clear" } }To get the same ordering as
withFixture, place yoursuper.beforeEach(TestData)call at the end of eachbeforeEach(TestData)method, and thesuper.afterEach(TestData)call at the beginning of eachafterEach(TestData)method, as shown in the previous example. It is a good idea to invokesuper.afterEach(TestData)in atryblock and perform cleanup in afinallyclause, as shown in the previous example, because this ensures the cleanup code is performed even ifsuper.afterEach(TestData)throws an exception.Besides enabling trait stacking, the other main advantage of
BeforeAndAfterEachTestDataoverBeforeAndAfteris thatBeforeAndAfterEachTestDataallows you to make use of test data (such as the test name and config map) in your before and/or after code, whereasBeforeAndAfterdoes not.The main disadvantage of
BeforeAndAfterEachTestDatacompared toBeforeAndAfterandBeforeAndAfterEachis thatBeforeAndAfterEachTestDatarequires more boilerplate. If you don't need trait stacking or access to the test data, useBeforeAndAfterinstead ofBeforeAndAfterEachTestData. If you need trait stacking, but not access to theTestData, useBeforeAndAfterEachinstead.