Spec
Related Doc:
package fixture
Returns an Alerter that during test execution will forward strings (and other objects) passed to its
apply method to the current reporter.
Returns an Alerter that during test execution will forward strings (and other objects) passed to its
apply method to the current reporter. If invoked in a constructor, it
will register the passed string for forwarding later during test execution. If invoked while this
Spec is being executed, such as from inside a test function, it will forward the information to
the current reporter immediately. If invoked at any other time, it will
print to the standard output. This method can be called safely by any thread.
The total number of tests that are expected to run when this Spec's run method is invoked.
The total number of tests that are expected to run when this Spec's run method is invoked.
This trait's implementation of this method returns the sum of:
testNames List, minus the number of tests marked as ignored and
any tests that are exluded by the passed FilterexpectedTestCount on every nested Suite contained in
nestedSuitesThis trait's implementation of this method will first ensure that the discovery of scope objects and test methods has been performed.
a Filter with which to filter tests to count based on their tags
the expected number test count
Returns an Informer that during test execution will forward strings passed to its
apply method to the current reporter.
Returns an Informer that during test execution will forward strings passed to its
apply method to the current reporter. If invoked in a constructor, it
will register the passed string for forwarding later during test execution. If invoked from inside a scope,
it will forward the information to the current reporter immediately. If invoked from inside a test function,
it will record the information and forward it to the current reporter only after the test completed, as recordedEvents
of the test completed event, such as TestSucceeded. If invoked at any other time, it will print to the standard output.
This method can be called safely by any thread.
Returns a Documenter that during test execution will forward strings passed to its
apply method to the current reporter.
Returns a Documenter that during test execution will forward strings passed to its
apply method to the current reporter. If invoked in a constructor, it
will register the passed string for forwarding later during test execution. If invoked from inside a scope,
it will forward the information to the current reporter immediately. If invoked from inside a test function,
it will record the information and forward it to the current reporter only after the test completed, as recordedEvents
of the test completed event, such as TestSucceeded. If invoked at any other time, it will print to the standard output.
This method can be called safely by any thread.
Returns a Notifier that during test execution will forward strings (and other objects) passed to its
apply method to the current reporter.
Returns a Notifier that during test execution will forward strings (and other objects) passed to its
apply method to the current reporter. If invoked in a constructor, it
will register the passed string for forwarding later during test execution. If invoked while this
Spec is being executed, such as from inside a test function, it will forward the information to
the current reporter immediately. If invoked at any other time, it will
print to the standard output. This method can be called safely by any thread.
Runs this fixture.Spec.
Runs this fixture.Spec.
If testName is None, this trait's implementation of this method
calls these two methods on this object in this order:
runNestedSuites(report, stopper, tagsToInclude, tagsToExclude, configMap, distributor)runTests(testName, report, stopper, tagsToInclude, tagsToExclude, configMap)If testName is defined, then this trait's implementation of this method
calls runTests, but does not call runNestedSuites. This behavior
is part of the contract of this method. Subclasses that override run must take
care not to call runNestedSuites if testName is defined. (The
OneInstancePerTest trait depends on this behavior, for example.)
This trait's implementation of this method will first ensure that the discovery of scope objects and test methods has been performed.
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 fixture.SpecLike.
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.
IllegalArgumentException if testName is defined, but no test with the specified test name
exists in this Suite
NullArgumentException if any passed parameter is null.
Run a test.
Run a test. This trait's implementation runs the test registered with the name specified by
testName. Each test's name is a concatenation of the text of all scope objects surrounding a test,
from outside in, and the test method's name, with one space placed between each item. (See the documentation
for testNames for an example.)
This trait's implementation of this method will first ensure that the discovery of scope objects and test methods has been performed.
the name of one test to execute.
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 .
NullArgumentException if testName or args is null.
Run zero to many of this Spec's tests.
Run zero to many of this Spec'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 Spec.
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.
IllegalArgumentException if testName is defined, but no test with the specified test name
exists in this Spec
NullArgumentException if any of the passed parameters is null.
Suite style name.
A Map whose keys are String tag names to which tests in this Spec belong, and values
the Set of test names that belong to each tag.
A Map whose keys are String tag names to which tests in this Spec belong, and values
the Set of test names that belong to each tag. If this Spec contains no tags, this method returns an empty Map.
This trait's implementation returns tags that were passed as strings contained in Tag objects passed to
methods test and ignore.
In addition, this trait's implementation will also auto-tag tests with class level annotations. For example, if you annotate @Ignore at the class level, all test methods in the class will be auto-annotated with @Ignore.
This trait's implementation of this method will first ensure that the discovery of scope objects and test methods has been performed.
An immutable Set of test names.
An immutable Set of test names. If this Spec contains no tests, this method returns an
empty Set.
This trait's implementation of this method will return a set that contains the names of all registered tests. The set's
iterator will return those names in the order in which the tests were registered. Each test's name is composed
of the concatenation of the name of each surrounding scope object, in order from outside in, and the name of the
test method itself, with all components separated by a space. For example, consider this Spec:
import org.scalatest.Spec
class StackSpec extends Spec {
object `A Stack` {
object `(when not empty)` {
def `must allow me to pop` {}
}
object `(when not full)` {
def `must allow me to push` {}
}
}
}
Invoking testNames on this Spec will yield a set that contains the following
two test name strings:
"A Stack (when not empty) must allow me to pop" "A Stack (when not full) must allow me to push"
This trait's implementation of this method will first ensure that the discovery of scope objects and test methods has been performed.
the Set of test names
Returns a user friendly string for this suite, composed of the
simple name of the class (possibly simplified further by removing dollar signs if added by the Scala interpeter) and, if this suite
contains nested suites, the result of invoking toString on each
of the nested suites, separated by commas and surrounded by parentheses.
Returns a user friendly string for this suite, composed of the
simple name of the class (possibly simplified further by removing dollar signs if added by the Scala interpeter) and, if this suite
contains nested suites, the result of invoking toString on each
of the nested suites, separated by commas and surrounded by parentheses.
a user-friendly string for this suite
A sister class to
org.scalatest.Specthat can pass a fixture object into its tests.fixture.Specin situations for whichSpecwould be a good choice, when all or most tests need the same fixture objects that must be cleaned up afterwards. Note:fixture.Specis intended for use in special situations, with classSpecused for general needs. For more insight into wherefixture.Specfits in the big picture, see thewithFixture(OneArgTest)subsection of the Shared fixtures section in the documentation for classSpec.Class
fixture.Specbehaves similarly to classorg.scalatest.Spec, except that tests may have a fixture parameter. The type of the fixture parameter is defined by the abstractFixtureParamtype, which is a member of this class. This class also has an abstractwithFixturemethod. ThiswithFixturemethod takes aOneArgTest, which is a nested trait defined as a member of this class.OneArgTesthas anapplymethod that takes aFixtureParam. Thisapplymethod is responsible for running a test. This class'srunTestmethod delegates the actual running of each test towithFixture(OneArgTest), passing in the test code to run via theOneArgTestargument. ThewithFixture(OneArgTest)method (abstract in this class) is responsible for creating the fixture argument and passing it to the test function.Subclasses of this class must, therefore, do three things differently from a plain old
org.scalatest.Spec:FixtureParamwithFixture(OneArgTest)methodIf the fixture you want to pass into your tests consists of multiple objects, you will need to combine them into one object to use this class. One good approach to passing multiple fixture objects is to encapsulate them in a case class. Here's an example:
To enable the stacking of traits that define
withFixture(NoArgTest), it is a good idea to letwithFixture(NoArgTest)invoke the test function instead of invoking the test function directly. To do so, you'll need to convert theOneArgTestto aNoArgTest. You can do that by passing the fixture object to thetoNoArgTestmethod ofOneArgTest. In other words, instead of writing “test(theFixture)”, you'd delegate responsibility for invoking the test function to thewithFixture(NoArgTest)method of the same instance by writing:Here's a complete example:
package org.scalatest.examples.spec.oneargtest import org.scalatest.fixture import java.io._ class ExampleSpec extends fixture.Spec { case class FixtureParam(file: File, writer: FileWriter) def withFixture(test: OneArgTest) = { // create the fixture val file = File.createTempFile("hello", "world") val writer = new FileWriter(file) val theFixture = FixtureParam(file, writer) try { writer.write("ScalaTest is ") // set up the fixture withFixture(test.toNoArgTest(theFixture)) // "loan" the fixture to the test } finally writer.close() // clean up the fixture } object `Testing ` { def `should be easy` { f: FixtureParam => f.writer.write("easy!") f.writer.flush() assert(f.file.length === 18) } def `should be fun` { f: FixtureParam => f.writer.write("fun!") f.writer.flush() assert(f.file.length === 17) } } }If a test fails, the
OneArgTestfunction will result in a Failed wrapping the exception describing the failure. To ensure clean up happens even if a test fails, you should invoke the test function from inside atryblock and do the cleanup in afinallyclause, as shown in the previous example.Sharing fixtures across classes
If multiple test classes need the same fixture, you can define the
FixtureParamandwithFixture(OneArgTest)implementations in a trait, then mix that trait into the test classes that need it. For example, if your application requires a database and your integration tests use that database, you will likely have many test classes that need a database fixture. You can create a "database fixture" trait that creates a database with a unique name, passes the connector into the test, then removes the database once the test completes. This is shown in the following example:package org.scalatest.examples.fixture.spec.sharing import java.util.concurrent.ConcurrentHashMap import org.scalatest.fixture import DbServer._ import java.util.UUID.randomUUID object DbServer { // Simulating a database server type Db = StringBuffer private val databases = new ConcurrentHashMap[String, Db] def createDb(name: String): Db = { val db = new StringBuffer databases.put(name, db) db } def removeDb(name: String) { databases.remove(name) } } trait DbFixture { this: fixture.Suite => type FixtureParam = Db // Allow clients to populate the database after // it is created def populateDb(db: Db) {} def withFixture(test: OneArgTest) = { val dbName = randomUUID.toString val db = createDb(dbName) // create the fixture try { populateDb(db) // setup the fixture withFixture(test.toNoArgTest(db)) // "loan" the fixture to the test } finally removeDb(dbName) // clean up the fixture } } class ExampleSpec extends fixture.Spec with DbFixture { override def populateDb(db: Db) { // setup the fixture db.append("ScalaTest is ") } object `Testing ` { def `should be easy` (db: Db) { db.append("easy!") assert(db.toString === "ScalaTest is easy!") } def `should be fun` (db: Db) { db.append("fun!") assert(db.toString === "ScalaTest is fun!") } } // This test doesn't need a Db object `Test code` { def `should be clear` { val buf = new StringBuffer buf.append("ScalaTest code is ") buf.append("clear!") assert(buf.toString === "ScalaTest code is clear!") } } }Often when you create fixtures in a trait like
DbFixture, you'll still need to enable individual test classes to "setup" a newly created fixture before it gets passed into the tests. A good way to accomplish this is to pass the newly created fixture into a setup method, likepopulateDbin the previous example, before passing it to the test function. Classes that need to perform such setup can override the method, as doesExampleSpec.If a test doesn't need the fixture, you can indicate that by leaving off the fixture parameter, as is done in the third test in the previous example, “
Test code should be clear”. For such methods,runTestwill not invokewithFixture(OneArgTest). It will instead directly invokewithFixture(NoArgTest).Both examples shown above demonstrate the technique of giving each test its own "fixture sandbox" to play in. When your fixtures involve external side-effects, like creating files or databases, it is a good idea to give each file or database a unique name as is done in these examples. This keeps tests completely isolated, allowing you to run them in parallel if desired. You could mix
ParallelTestExecutioninto either of theseExampleSpecclasses, and the tests would run in parallel just fine.