Event used to provide alert notifications.
Event that indicates a runner has completed searching for suites.
Event that indicates a runner has completed searching for suites.
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
an optional amount of time, in milliseconds, that was required by the run that has completed
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
Event that indicates a runner is beginning search for suites to run.
Event that indicates a runner is beginning search for suites to run.
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
a ConfigMap
of key-value pairs that can be used by custom Reporter
s
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
A base class for the events that can be passed to the report function passed
to the execute
method of a Suite
.
A base class for the events that can be passed to the report function passed
to the execute
method of a Suite
.
Marker trait for test failed and test canceled events.
Abstract class for the optional formatter objects that must be passed to the Event
s reported
during a ScalaTest run.
Abstract class for the optional formatter objects that must be passed to the Event
s reported
during a ScalaTest run.
A Formatter
providing information that enables reporters to create more stylized output.
A Formatter
providing information that enables reporters to create more stylized output.
An example is that specification-style suites, such as FunSpec
, generate output that reads
more like a specification, for instance:
A Stack (when newly created) - should be empty - should complain when popped
This output might be generated by ScalaTest's standard out reporter. Each of these lines would be
taken from the IndentedText
's formattedText
parameter. Were this same run
to be reported in HTML or in a GUI, the output would be based on the rawText
and the
indentationLevel
. Here's what the IndentedText
values would be for each event:
InfoProvided
reported with an:
IndentedText( formattedText = "A Stack (when newly created)", rawText = "A Stack (when newly created)", indentationLevel = 0 )
TestSucceeded
reported with an:
IndentedText( formattedText = "- should be empty", rawText = "should be empty", indentationLevel = 1 )
TestSucceeded
reported with an:
IndentedText( formattedText = "- should complain when popped", rawText = "should complain when popped", indentationLevel = 1 )
One possible way this information could be presented in HTML, for example, is this:
A Stack (when newly created)
a localized string suitable for presenting to a user by printing it straight to an output stream
a localized string suitable for presenting to the user after in some way being indented by the
value specified as the indentationLevel
parameter
a zero or positive integer representing an indentation level for the indented text
IllegalArgumentException
if the specified indentationLevel
is less than zero
Event used to provide information that is not appropriate to report via any other Event
.
Event used to provide information that is not appropriate to report via any other Event
.
To create instances of this class you may
use the factory method provided in its companion object. For example, given a
report function named report
, you could fire a InfoProvided
event like this:
report(InfoProvided(ordinal, message, Some(NameInfo(suiteName, suiteId, Some(thisSuite.getClass.getName), Some(testName)))))
An InfoProvided
event may be fired from anywhere. In this respect InfoProvided
is different
from events for which it is defined whether they are fired in the context of a suite or test.
If fired in the context of a test, the InfoProvided
event should include a NameInfo
in which
testName
is defined. If fired in the context of a suite, but not a test, the InfoProvided
event
should include a NameInfo
in which testName
is not defined. If fired within the context
of neither a suite nor a test, the nameInfo
of the InfoProvided
event (an Option[NameInfo]
) should be None
.
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
a localized message suitable for presenting to the user
an optional NameInfo
that if defined, provides names for the suite and optionally the test
in the context of which the information was provided
an optional Throwable
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional object that can be used to pass custom information to the reporter about the InfoProvided
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
An arbitrary line number in a named source file.
An arbitrary line number in a named source file.
the line number
the source file's simple name
an optional fully qualified pathname of the source file
Location in source code indicating where in the source code an event originated.
Event used to provide markup text for document-style reports.
Event used to provide markup text for document-style reports.
To create instances of this class you may
use the factory method. For example, given a report function named report
, you could fire a MarkupProvided
event like this:
report(MarkupProvided(ordinal, text, Some(NameInfo(suiteName, suiteId, Some(thisSuite.getClass.getName), Some(testName)))))
A MarkupProvided
event may be fired from anywhere. In this respect MarkupProvided
is different
from the other events, for which it is defined whether they are fired in the context of a suite or test.
If fired in the context of a test, the MarkupProvided
event should include a NameInfo
in which
testName
is defined. If fired in the context of a suite, but not a test, the MarkupProvided
event
should include a NameInfo
in which testName
is not defined. If fired within the context
of neither a suite nor a test, the nameInfo
of the MarkupProvided
event (an Option[NameInfo]
) should be None
.
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
a snippet of markup text (in Markdown format)
an optional NameInfo
that if defined, provides names for the suite and optionally the test
in the context of which the information was provided
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional object that can be used to pass custom information to the reporter about the MarkupProvided
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
Class that holds information about names for the information events InfoProvided
, MarkupProvided
,
ScopeOpened
, ScopeClosed
, ScopePending
, AlertProvided
and NoteProvided
.
Class that holds information about names for the information events InfoProvided
, MarkupProvided
,
ScopeOpened
, ScopeClosed
, ScopePending
, AlertProvided
and NoteProvided
.
An information event may be fired from anywhere. In this respect these events are different
from the other events, for which it is defined whether they are fired in the context of a suite or test.
If fired in the context of a test, an information event event should include a NameInfo
in which
testName
is defined. If fired in the context of a suite, but not a test, the InfoProvided
event
should include a NameInfo
in which testName
is not defined. If fired within the context
of neither a suite nor a test, the nameInfo
of the InfoProvided
event (an Option[NameInfo]
) should be None
.
If either suiteClassName
or testName
is defined, then suiteName
and suiteId
must be defined.
The suite class name parameter is optional even if a suite name is provided by passing a Some
as suiteName
,
because suites in ScalaTest are an abstraction that
need not necessarily correspond to one class. Nevertheless, in most cases each suite will correspond
to a class, and when it does, the fully qualified name of that class should be reported by passing a
Some
for suiteClassName
. One use for this bit of information is JUnit integration,
because the "name" provided to a JUnit org.junit.runner.Description
appears to usually include
a fully qualified class name by convention.
an optional name of the suite about which an information event was fired
an optional string ID for the suite about which an information event was fired, intended to be unique across all suites in a run
an optional fully qualifed Suite
class name about which the information was provided
an optional test name information
Event used to provide notifications.
Event used to provide notifications.
To create instances of this class you may use the factory method. For example, given a
report function named report
, you could fire a NoteProvided
event like this:
report(NoteProvided(ordinal, message, Some(NameInfo(suiteName, suiteId, Some(thisSuite.getClass.getName), Some(testName)))))
NoteProvided
differs from InfoProvided
in that unlike InfoProvided
, NoteProvided
isn't
a RecordableEvent
. If fired because of a note
call from a test, for example, the NoteProvided
will immediately
be sent to the reporters rather than being stored and sent in the recordedEvents
field of the test completion event. Thus,
NoteProvided
enables "status notifications" to be provided
while tests are happening. The difference between NoteProvided
and AlertProvided
, which is also a "status notification"
fired immediately during tests, is that AlertProvided
is intended for warnings, where as NoteProvided
is just
for information. As an illustration, AlertProvided
messages are displayed in yellow, NoteProvided
in green,
in the stdout, stderr, and file reporters.
An NoteProvided
event may be fired from anywhere. In this respect NoteProvided
is different
from events for which it is defined whether they are fired in the context of a suite or test.
If fired in the context of a test, the NoteProvided
event should include a NameInfo
in which
testName
is defined. If fired in the context of a suite, but not a test, the NoteProvided
event
should include a NameInfo
in which testName
is not defined. If fired within the context
of neither a suite nor a test, the nameInfo
of the NoteProvided
event (an Option[NameInfo]
) should be None
.
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
a localized message suitable for presenting to the user
an optional NameInfo
that if defined, provides names for the suite and optionally the test
in the context of which the information was provided
an optional Throwable
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional object that can be used to pass custom information to the reporter about the NoteProvided
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
Marker trait for the "notification" events NoteProvided
and AlertProvided
.
Marker trait for the "notification" events NoteProvided
and AlertProvided
.
Class used to specify a sequential order for events reported during a test run, so they can be arranged in that order in a report even if the events were fired in some other order during concurrent or distributed execution.
Class used to specify a sequential order for events reported during a test run, so they can be arranged in that order in a report even if the events were fired in some other order during concurrent or distributed execution.
An Ordinal
is an immutable object holding a run stamp and a sequence
of stamps.
The run stamp is an integer that identifies a particular run. All events
reported during the same run should share the same run stamp. By contrast, each
event reported during a particular run should have a different stamp sequence.
One use case for the run stamp is that the initial run from ScalaTest's GUI
will have run stamp 0. Subsequent reruns will have run stamps 1,
2, 3, etc., so that reports in the GUI can simply be sorted in "ordinal" order. Another
use case is a set of servers used to run multiple tests simultaneously in a distributed
fashion. The run stamp can be used to identify the run to which an event belongs.
The stamp sequence is designed to allow a sequential order of events to be specified during
concurrent execution of ScalaTest suites. ScalaTest's model for concurrent execution is that
the suites that make up a run may be executed concurrently, but the tests within a single suite
will be executed sequentially. In addition to tests, suites may contain nested suites. The default implementation
of execute
in class Suite
will first invoke runNestedSuites
and
then runTests
. If no Distributor
is passed to execute
, the
runNestedSuites
method will execute the nested suites sequentially via the same thread
that invoked runNestedSuites
. As a result, suites will by default executed in depth first order
when executed sequentially. If a Distributor
is passed to execute
, the
runNestedSuites
method will simply put its nested suites into the Distributor
and return. Some other threads or processes must then execute those nested suites. Given the default
implementations of execute
and runNestedSuites
described here, the Ordinal
will allow the events from a concurrent run to be sorted in the same depth-first order that the events
from a corresponding sequential run would arrive.
Each event reported during a run should be given a unique Ordinal
. An Ordinal
is required
by all Event
subclasses, instances of which are used to send information to the report
function passed to a Suite
's execute
method. The first Ordinal
for a run
can be produced by passing a run stamp to Ordinal
's lone public constructor:
val firstOrdinal = new Ordinal(99)
The run stamp can be any integer. The Ordinal
created in this way can be passed along with the first
reported event of the run, such as a RunStarting
event. Thereafter, new Ordinal
s for the same run
can be obtained by calling either next
or nextNewOldPair
on the previously obtained Ordinal
.
In other words, given an Ordinal
, you can obtain the next Ordinal
by invoking one of these two
"next" methods on the Ordinal
you have in hand. Before executing a new Suite
, the nextNewOldPair
method should be invoked. This will return two new Ordinal
s, one for the new Suite
about to be executed, and
one for the currently executing entity (either a Suite
or some sort of test runner). At any other time, the next Ordinal
can be obtained by simply invoking next
on the current Ordinal
.
You can convert an Ordinal
to a List
by invoking toList
on it. The resulting List
will contain
the run stamp as its first element, and the contents of its stamps sequence as the subsequent elements. The stamps
sequence will initially be composed of a single element with the value 0. Thus, toList
invoked on the firstOrdinal
shown above will
result in:
firstOrdinal.toList // results in: List(99, 0)
Each time next
is invoked, the rightmost integer returned by toList
will increment:
val secondOrdinal = firstOrdinal.next secondOrdinal.toList // results in: List(99, 1) val thirdOrdinal = secondOrdinal.next thirdOrdinal.toList // result is : List(99, 2)
When nextNewOldPair
is invoked the result will be a tuple whose first element is the first Ordinal
for
the new Suite
about to be executed (for example, a nested Suite
of the currently executing Suite
). The
second element is the next Ordinal
for the currently executing Suite
or other entity:
val (nextForNewSuite, nextForThisRunner) = thirdOrdinal.nextNewOldPair nextForNewSuite.toList // results in: (99, 2, 0) nextForThisRunner.toList // results in: (99, 3)
The toList
method of the Ordinal
for the new suite starts with the same sequence of elements as the Ordinal
from which it was
created, but has one more element, a 0, appended at the end. Subsequent invocations of next
on this series of Ordinal
s will
increment that last element:
val newSuiteOrdinal2 = nextForNewSuite.next newSuiteOrdinal2.toList // results in: List(99, 2, 1) val newSuiteOrdinal3 = newSuiteOrdinal2.next newSuiteOrdinal3.toList // result is : List(99, 2, 2)
This behavior allows events fired by Suite
running concurrently to be reordered in a pre-determined sequence after all the events
have been reported. The ordering of two Ordinal
s can be determined by first comparing the first element of the List
s obtained
by invoking toList
on both Ordinal
s. These values represent the runStamp
. If one run stamp is a lower number than
the other, that Ordinal
comes first. For example, an Ordinal
with a run stamp of 98 is ordered before an Ordinal
with
a run stamp of 99. If the run stamps are equal, the next number in the list is inspected. As with the run stamps, an Ordinal
with a lower
number is ordered before an Ordinal
with a higher number. If two corresponding elements are equal, the next pair of elements will be inspected.
This will continue no down the length of the List
s until a position is found where the element values are not equal, or the end of one or both of
the List
s are reached. If the two List
s are identical all the way to the end, and both List
s have the same lengths,
then the Ordinal
s are equal. (Equal Ordinal
s will not happen if correctly used by creating a new Ordinal
for
each fired event and each new Suite
.). If the two List
s are identical all the way to the end of one, but the other List
is longer (has more elements), then the shorter list is ordered before the longer one.
As an example, here are some Ordinal
List
forms in order:
List(99, 0) List(99, 1) List(99, 2) List(99, 2, 0) List(99, 2, 1) List(99, 2, 2) List(99, 2, 2, 0) List(99, 2, 2, 1) List(99, 2, 2, 2) List(99, 2, 3) List(99, 2, 4) List(99, 2, 4, 0) List(99, 2, 4, 1) List(99, 2, 4, 2) List(99, 3) List(99, 4) List(99, 4, 0) List(99, 4, 1) List(99, 5)
Marker trait for test completed event's recordedEvents.
Event that indicates a runner encountered an error while attempting to run a suite of tests.
Event that indicates a runner encountered an error while attempting to run a suite of tests.
For example, object Runner
reports RunAborted
if the
execute
method of any of the run's starting Suite
s completes
abruptly with a Throwable
.
ScalaTest's Runner
fires a RunAborted
report with an empty summary
, because
the reporter is responsible for keeping track of the total number of tests reported as succeeded, failed, ignored, and pending.
ScalaTest's internal reporter replaces the RunAborted
with a new one that is identical except that is
has a defined summary
.
To create instances of this class you may
use the factory method. For example, given a report function named report
, you could fire a RunAborted
event like this:
report(RunAborted(ordinal, message, Some(exception)))
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
a localized message suitable for presenting to the user
an optional Throwable
that, if a Some
, indicates why the run has aborted,
or a Throwable
created to capture stack trace information about the problem.
an optional amount of time, in milliseconds, that was required by the run that has aborted
an optional Summary
of the number of tests that were reported as succeeded, failed, ignored, and pending
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional object that can be used to pass custom information to the reporter about the RunAborted
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
Event that indicates a runner has completed running a suite of tests.
Event that indicates a runner has completed running a suite of tests.
Suite
's execute
method takes a Stopper
, whose stopRequested
method indicates a stop was requested. If true
is returned by
stopRequested
while a suite of tests is running, the
execute
method should promptly
return even if that suite hasn't finished running all of its tests.
If a stop was requested via the Stopper
.
Runner
will report RunStopped
when the execute
method of the run's starting Suite
returns.
If a stop is not requested, Runner
will report RunCompleted
when the last execute
method of the run's starting Suite
s returns.
ScalaTest's Runner
fires a RunCompleted
report with an empty summary
, because
the reporter is responsible for keeping track of the total number of tests reported as succeeded, failed, ignored, pending
and canceled. ScalaTest's internal reporter replaces the RunCompleted
with a new one that is identical except
that is has a defined summary
.
To create instances of this class you may
use the factory method. For example, given a report function named report
, you could fire a RunCompleted
event like this:
report(RunCompleted(ordinal))
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
an optional amount of time, in milliseconds, that was required by the run that has completed
an optional Summary
of the number of tests that were reported as succeeded, failed, ignored, pending and canceled
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional object that can be used to pass custom information to the reporter about the RunCompleted
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
Event that indicates a runner is about run a suite of tests.
Event that indicates a runner is about run a suite of tests.
For example, object Runner
reports RunStarting
to indicate
that the first execute
method of a run's initial Suite
is about to be invoked.
To create instances of this class you may
use the factory method. For example, given a report function named report
, you could fire a RunStarting
event like this:
report(RunStarting(ordinal, testCount))
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
the number of tests expected during this run
a ConfigMap
of key-value pairs that can be used by custom Reporter
s
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional object that can be used to pass custom information to the reporter about the RunStarting
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
IllegalArgumentException
if testCount
is less than zero.
Event that indicates a runner has stopped running a suite of tests prior to completion, likely because of a stop request.
Event that indicates a runner has stopped running a suite of tests prior to completion, likely because of a stop request.
Suite
's execute
method takes a Stopper
, whose stopRequested
method indicates a stop was requested. If true
is returned by
stopRequested
while a suite of tests is running, the
execute
method should promptly
return even if that suite hasn't finished running all of its tests.
If a stop was requested via the Stopper
.
Runner
will report RunStopped
when the execute
method of the run's starting Suite
returns.
If a stop is not requested, Runner
will report RunCompleted
when the last execute
method of the run's starting Suite
s returns.
ScalaTest's Runner
fires a RunStopped
report with an empty summary
, because
the reporter is responsible for keeping track of the total number of tests reported as succeeded, failed, ignored,
pending and canceled. ScalaTest's internal reporter replaces the RunStopped
with a new one that is
identical except that is has a defined summary
.
To create instances of this class you may use the factory method. For example, given a
report function named report
, you could fire a RunStopped
event like this:
report(RunStopped(ordinal))
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
an optional amount of time, in milliseconds, that was required by the run that has stopped
an optional summary of the number of tests that were reported as succeeded, failed, ignored pending and canceled
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional object that can be used to pass custom information to the reporter about the RunStopped
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
Event that indicates a scope has been closed.
Event that indicates a scope has been closed.
To create instances of this class you may
use the factory method. For example, given a report function named report
, you could fire a ScopeClosed
event like this:
report(ScopeClosed(ordinal, message, Some(NameInfo(suiteName, suiteId, Some(thisSuite.getClass.getName), Some(testName)))))
A ScopeClosed
event may be fired from within suites or tests.
If fired in the context of a test, the ScopeClosed
event should include a NameInfo
in which
testName
is defined. If fired in the context of a suite, but not a test, the ScopeClosed
event
should include a NameInfo
in which testName
is not defined.
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
a localized message suitable for presenting to the user
a NameInfo
that provides names for the suite and optionally the test
in the context of which the scope was closed
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional object that can be used to pass custom information to the reporter about the ScopeClosed
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
Event that indicates a new scope has been opened.
Event that indicates a new scope has been opened.
To create instances of this class you may
use the factory method. For example, given a report function named report
, you could fire a ScopeOpened
event like this:
report(ScopeOpened(ordinal, message, Some(NameInfo(suiteName, suiteId, Some(thisSuite.getClass.getName), Some(testName)))))
A ScopeOpened
event may be fired from within suites or tests.
If fired in the context of a test, the ScopeOpened
event should include a NameInfo
in which
testName
is defined. If fired in the context of a suite, but not a test, the ScopeOpened
event
should include a NameInfo
in which testName
is not defined.
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
a localized message suitable for presenting to the user
a NameInfo
that provides names for the suite and optionally the test
in the context of which the scope was opened
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional object that can be used to pass custom information to the reporter about the ScopeOpened
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
Event that indicates a scope is pending.
Event that indicates a scope is pending.
To create instances of this class you may
use the factory method. For example, given a report function named report
, you could fire a ScopePending
event like this:
report(ScopePending(ordinal, message, Some(NameInfo(suiteName, Some(thisSuite.getClass.getName), Some(testName)))))
A ScopePending
event is fired from within suites, and not tests.
The ScopePending
event should include a NameInfo
in which testName
is not defined.
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
a localized message suitable for presenting to the user
a NameInfo
that provides names for the suite and optionally the test
in the context of which the scope was closed
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional object that can be used to pass custom information to the reporter about the ScopePending
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
Event that indicates the execution of a suite of tests has aborted, likely because of an error, prior to completion.
Event that indicates the execution of a suite of tests has aborted, likely because of an error, prior to completion.
For example, trait Suite
and object Runner
use SuiteAborted
to report
that the execute
method of a Suite
has completed abruptly with a RuntimeException
.
To create instances of this class you may
use the factory method. For example, given a report function named report
, you could fire a SuiteAborted
event like this:
report(SuiteAborted(ordinal, userFriendlyName, message, suiteName, Some(thisSuite.getClass.getName)))
The suite class name parameter is optional, because suites in ScalaTest are an abstraction that
need not necessarily correspond to one class. Nevertheless, in most cases each suite will correspond
to a class, and when it does, the fully qualified name of that class should be reported by passing a
Some
for suiteClassName
. One use for this bit of information is JUnit integration,
because the "name" provided to a JUnit org.junit.runner.Description
appears to usually include
a fully qualified class name by convention.
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
suite name, suitable for presenting to the user
a localized message suitable for presenting to the user
a localized name identifying the suite that has aborted, suitable for presenting to the user
a string ID for the suite that has aborted, intended to be unique across all suites in a run
an optional fully qualifed Suite
class name containing the suite that has aborted
an optional Throwable
that, if a Some
, indicates why the suite has aborted,
or a Throwable
created to capture stack trace information about the problem.
an optional amount of time, in milliseconds, that was required to execute the suite that has aborted
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
an optional Location
that provides information indicating where in the source code an event originated.
an optional String
giving the fully qualified name of the class that can be used to rerun the suite that has aborted. (If None
is passed, the suite cannot be rerun.)
an optional object that can be used to pass custom information to the reporter about the SuiteAborted
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
Event that indicates a suite of tests has completed executing.
Event that indicates a suite of tests has completed executing.
For example, trait Suite
and object Runner
use SuiteCompleted
to report
that the execute
method of a Suite
has returned normally (without throwing a RuntimeException
).
To create instances of this class you may use the factory method. For example, given a
report function named report
, you could fire a SuiteCompleted
event like this:
report(SuiteCompleted(ordinal, userFriendlyName, suiteName, Some(thisSuite.getClass.getName)))
The suite class name parameter is optional, because suites in ScalaTest are an abstraction that
need not necessarily correspond to one class. Nevertheless, in most cases each suite will correspond
to a class, and when it does, the fully qualified name of that class should be reported by passing a
Some
for suiteClassName
. One use for this bit of information is JUnit integration,
because the "name" provided to a JUnit org.junit.runner.Description
appears to usually include
a fully qualified class name by convention.
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
a localized name identifying the suite that has completed, suitable for presenting to the user
a string ID for the suite that has completed, intended to be unique across all suites in a run
an optional fully qualifed Suite
class name containing the suite that has completed
an optional amount of time, in milliseconds, that was required to execute the suite that has completed
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional String
giving the fully qualified name of the class that can be used to rerun the suite that has completed. (If None
is passed, the suite cannot be rerun.)
an optional object that can be used to pass custom information to the reporter about the SuiteCompleted
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
Event that indicates a suite of tests is about to start executing.
Event that indicates a suite of tests is about to start executing.
For example, trait Suite
and object Runner
use SuiteStarting
to report
that the execute
method of a Suite
is about to be invoked.
To create instances of this class you may use the factory method. For example, given a
report function named report
, you could fire a SuiteStarting
event like this:
report(SuiteStarting(ordinal, userFriendlyName, suiteName, Some(thisSuite.getClass.getName)))
The suite class name parameter is optional, because suites in ScalaTest are an abstraction that
need not necessarily correspond to one class. Nevertheless, in most cases each suite will correspond
to a class, and when it does, the fully qualified name of that class should be reported by passing a
Some
for suiteClassName
. One use for this bit of information is JUnit integration,
because the "name" provided to a JUnit org.junit.runner.Description
appears to usually include
a fully qualified class name by convention.
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
a localized name identifying the suite that is starting, suitable for presenting to the user
a string ID for the suite that is starting, intended to be unique across all suites in a run XXX
an optional fully qualifed Suite
class name of the suite that is starting
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional String
giving the fully qualified name of the class that can be used to rerun the suite that is starting. (If None
is passed, the suite cannot be rerun.)
an optional object that can be used to pass custom information to the reporter about the SuiteStarting
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
Class each of whose instances hold summary information about one ScalaTest run.
Class each of whose instances hold summary information about one ScalaTest run.
the number of tests that were reported as succeeded during the run
the number of tests that were reported as failed during the run
the number of tests that were were reported as ignored during the run
the number of tests that were reported as pending during the run
the number of tests that were reported as canceled during the run
the number of suites that were reported as completed during the run
the number of suites that were reported as aborted during the run
the number of scopes that were reported as pending during the run
Event that indicates a test was canceled, i.e., it couldn't run because some precondition was not met.
Event that indicates a test was canceled, i.e., it couldn't run because some precondition was not met.
To create instances of this class you may
use the factory methods. For example, given a report function named report
, you could fire a TestCanceled
event like this:
report(TestCanceled(ordinal, userFriendlyName, suiteName, Some(thisSuite.getClass.getName), testName))
The suite class name parameter is optional, because suites in ScalaTest are an abstraction that
need not necessarily correspond to one class. Nevertheless, in most cases each suite will correspond
to a class, and when it does, the fully qualified name of that class should be reported by passing a
Some
for suiteClassName
. One use for this bit of information is JUnit integration,
because the "name" provided to a JUnit org.junit.runner.Description
appears to usually include
a fully qualified class name by convention.
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
a localized message suitable for presenting to the user
a localized name identifying the suite containing the test that was canceled, suitable for presenting to the user
a string ID for the suite containing the test that was canceled, intended to be unique across all suites in a run
an optional fully qualifed Suite
class name containing the test that was canceled
the name of the test that was canceled
the text of the test that was canceled (may be the test name, or a suffix of the test name)
recorded events in the test.
an optional Throwable
that, if a Some
, indicates why the test was canceled,
or a Throwable
created to capture stack trace information about the problem.
an optional amount of time, in milliseconds, that was required to run the test that was canceled
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional String
giving the fully qualified name of the class that can be used to rerun the test that has canceled. (If None
is passed, the test cannot be rerun.)
an optional object that can be used to pass custom information to the reporter about the TestCanceled
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
Event that indicates a suite (or other entity) has completed running a test that failed.
Event that indicates a suite (or other entity) has completed running a test that failed.
For example, trait Suite
uses TestFailed
to report
that a test method of a Suite
completed abruptly with an Exception
.
To create instances of this class you may
use the factory method. For example, given a report function named report
, you could fire a TestFailed
event like this:
report(TestFailed(ordinal, userFriendlyName, message, suiteName, Some(thisSuite.getClass.getName), testName))
The suite class name parameter is optional, because suites in ScalaTest are an abstraction that
need not necessarily correspond to one class. Nevertheless, in most cases each suite will correspond
to a class, and when it does, the fully qualified name of that class should be reported by passing a
Some
for suiteClassName
. One use for this bit of information is JUnit integration,
because the "name" provided to a JUnit org.junit.runner.Description
appears to usually include
a fully qualified class name by convention.
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
a localized message suitable for presenting to the user
a localized name identifying the suite containing the test that has failed, suitable for presenting to the user
a string ID for the suite containing the test that has failed, intended to be unique across all suites in a run
an optional fully qualifed Suite
class name containing the test that has failed
the name of the test that has failed
the text of the test that has failed (may be the test name, or a suffix of the test name)
recorded events in the test.
an optional Throwable
that, if a Some
, indicates why the test has failed,
or a Throwable
created to capture stack trace information about the problem.
an optional amount of time, in milliseconds, that was required to run the test that has failed
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional String
giving the fully qualified name of the class that can be used to rerun the test that has failed. (If None
is passed, the test cannot be rerun.)
an optional object that can be used to pass custom information to the reporter about the TestFailed
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
Event that indicates a suite (or other entity) has ignored a test.
Event that indicates a suite (or other entity) has ignored a test.
For example, trait Suite
uses TestIgnored
to report
that a test method of a Suite
was ignored because it was annotated with @Ignore
.
Ignored tests will not be run, but will usually be reported as reminder to fix the broken test.
To create instances of this class you may use the factory method. For example, given a
report function named report
, you could fire a TestIgnored
event like this:
report(TestIgnored(ordinal, userFriendlyName, suiteName, Some(thisSuite.getClass.getName), testName))
The suite class name parameter is optional, because suites in ScalaTest are an abstraction that
need not necessarily correspond to one class. Nevertheless, in most cases each suite will correspond
to a class, and when it does, the fully qualified name of that class should be reported by passing a
Some
for suiteClassName
. One use for this bit of information is JUnit integration,
because the "name" provided to a JUnit org.junit.runner.Description
appears to usually include
a fully qualified class name by convention.
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
a localized name identifying the suite containing the test that was ignored, suitable for presenting to the user
a string ID for the suite containing the test that was ignored, intended to be unique across all suites in a run
an optional fully qualifed Suite
class name containing the test that was ignored
the name of the test that was ignored
the text of the test that was ignored (may be the test name, or a suffix of the test name)
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional object that can be used to pass custom information to the reporter about the TestIgnored
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
Event that indicates a test is pending, i.e., it hasn't yet been implemented.
Event that indicates a test is pending, i.e., it hasn't yet been implemented.
To create instances of this class you may
use the factory method. For example, given a report function named report
, you could fire a TestPending
event like this:
report(TestPending(ordinal, userFriendlyName, suiteName, Some(thisSuite.getClass.getName), testName))
The suite class name parameter is optional, because suites in ScalaTest are an abstraction that
need not necessarily correspond to one class. Nevertheless, in most cases each suite will correspond
to a class, and when it does, the fully qualified name of that class should be reported by passing a
Some
for suiteClassName
. One use for this bit of information is JUnit integration,
because the "name" provided to a JUnit org.junit.runner.Description
appears to usually include
a fully qualified class name by convention.
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
a localized name identifying the suite containing the test that is pending, suitable for presenting to the user
a string ID for the suite containing the test that is pending, intended to be unique across all suites in a run
an optional fully qualifed Suite
class name containing the test that is pending
the name of the test that is pending
the text of the test that is pending (may be the test name, or a suffix of the test name)
recorded events in the test.
an optional amount of time, in milliseconds, that was required to run the test that is pending
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional object that can be used to pass custom information to the reporter about the TestPending
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
Event that indicates a suite (or other entity) is about to start running a test.
Event that indicates a suite (or other entity) is about to start running a test.
For example, trait Suite
uses TestStarting
to report
that a test method of a Suite
is about to be invoked.
To create instances of this class you may use the factory method. For example,
given a report function named report
, you could fire a TestStarting
event like this:
report(TestStarting(ordinal, userFriendlyName, suiteName, Some(thisSuite.getClass.getName), testName))
The suite class name parameter is optional, because suites in ScalaTest are an abstraction that
need not necessarily correspond to one class. Nevertheless, in most cases each suite will correspond
to a class, and when it does, the fully qualified name of that class should be reported by passing a
Some
for suiteClassName
. One use for this bit of information is JUnit integration,
because the "name" provided to a JUnit org.junit.runner.Description
appears to usually include
a fully qualified class name by convention.
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
a localized name identifying the suite containing the test that is starting, suitable for presenting to the user
a string ID for the suite containing the test that is starting, intended to be unique across all suites in a run
an optional fully qualifed Suite
class name containing the test that is starting
the name of the test that is starting
the text of the test that is starting (may be the test name, or a suffix of the test name)
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional String
giving the fully qualified name of the class that can be used to rerun the test that is starting. (If None
is passed, the test cannot be rerun.)
an optional object that can be used to pass custom information to the reporter about the TestStarting
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
Event that indicates a suite (or other entity) has completed running a test that succeeded.
Event that indicates a suite (or other entity) has completed running a test that succeeded.
For example, trait Suite
uses TestSucceeded
to report
that a test method of a Suite
returned normally
(without throwing an Exception
).
To create instances of this class you may use the factory method. For example, given a
report function named report
, you could fire a TestSucceeded
event like this:
report(TestSucceeded(ordinal, userFriendlyName, suiteName, Some(thisSuite.getClass.getName), testName))
The suite class name parameter is optional, because suites in ScalaTest are an abstraction that
need not necessarily correspond to one class. Nevertheless, in most cases each suite will correspond
to a class, and when it does, the fully qualified name of that class should be reported by passing a
Some
for suiteClassName
. One use for this bit of information is JUnit integration,
because the "name" provided to a JUnit org.junit.runner.Description
appears to usually include
a fully qualified class name by convention.
an Ordinal
that can be used to place this event in order in the context of
other events reported during the same run
a localized name identifying the suite containing the test that has succeeded, suitable for presenting to the user
a string ID for the suite containing the test that has succeeded, intended to be unique across all suites in a run
an optional fully qualifed Suite
class name containing the test that has succeeded
the name of the test that has succeeded
the text of the test that has succeeded (may be the test name, or a suffix of the test name)
recorded events in the test.
an optional amount of time, in milliseconds, that was required to run the test that has succeeded
an optional Formatter
that provides extra information that can be used by reporters in determining
how to present this event to the user
An optional Location
that provides information indicating where in the source code an event originated.
an optional String
giving the fully qualified name of the class that can be used to rerun the test that has succeeded. (If None
is passed, the test cannot be rerun.)
an optional object that can be used to pass custom information to the reporter about the TestSucceeded
event
a name for the Thread
about whose activity this event was reported
a Long
indicating the time this event was reported, expressed in terms of the
number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT
The location in a source file where the class whose by the fully qualified name
is passed as className
is declared.
The location in a source file where the class whose by the fully qualified name
is passed as className
is declared.
the fully qualified class name
The location in a source file where the method identified by the passed methodId
in the class whose fully qualified name is pased as className
is declared.
The location in a source file where the method identified by the passed methodId
in the class whose fully qualified name is pased as className
is declared.
The methodId is obtained by calling toGenericString
on the java.lang.reflect.Method
object representing the method.
the fully qualified class name
the method ID, obtained by calling toGenericString
on the java.lang.reflect.Method
object representing the method
A Formatter
that indicates reporters may wish to suppress reporting of an Event
.
A Formatter
that indicates reporters may wish to suppress reporting of an Event
.
"Suppress" means that the event won't be reported to the user.
An example is that specification-style suites, such as FunSpec
, generate output that reads
more like a specification. One aspect of this is that generally only a single event should be reported
for each test, so that output can appear like this:
A Stack (when newly created) - should be empty - should complain when popped
ScalaTest suites should generate two events per test, a TestStarting
event and either
a TestSucceeded
or a TestFailed
event. The FunSpec
trait does report both events,
but passes a MotionToSuppress
along with the TestStarting
event. As a result,
The TestStarting
events have no effect on the output. Each TestSucceeded
or
TestFailed
event, which is sent with an IndentedText
formatter instead of
a MotionToSuppress
, will generate output, such as "- should be empty
".
Reporters may choose to ignore a MotionToSuppress
. For example, an XML reporter may
want to report everything about every event that is fired during a concurrent run, so that the
events can be reordered later by reading the complete, but unordered, information from an XML file.
In this case, the XML reporter would actually report events that were fired with a MotionToSuppress
,
including indicating that the report included a motion to suppress.
Indicates the location should be taken from the stack depth exception, included elsewhere in the event that contained this location.
Event used to provide alert notifications.
To create instances of this class you may use the factory method. For example, given a report function named
report
, you could fire anAlertProvided
event like this:AlertProvided
differs fromInfoProvided
in that unlikeInfoProvided
,AlertProvided
isn't aRecordableEvent
. If fired becase of analert
call from a test, for example, theAlertProvided
will immediately be sent to the reporters rather than being stored and sent in therecordedEvents
field of the test completion event. Thus,AlertProvided
enables "status notifications" to be provided while tests are happening. The difference betweenAlertProvided
andNoteProvided
, which is also a "status notification" fired immediately during tests, is thatAlertProvided
is intended for warnings, where asNoteProvided
is just for information. As an illustration,AlertProvided
messages are displayed in yellow,NoteProvided
in green, in the stdout, stderr, and file reporters.An
AlertProvided
event may be fired from anywhere. In this respectAlertProvided
is different from events for which it is defined whether they are fired in the context of a suite or test. If fired in the context of a test, theAlertProvided
event should include aNameInfo
in whichtestName
is defined. If fired in the context of a suite, but not a test, theAlertProvided
event should include aNameInfo
in whichtestName
is not defined. If fired within the context of neither a suite nor a test, thenameInfo
of theAlertProvided
event (anOption[NameInfo]
) should beNone
.an
Ordinal
that can be used to place this event in order in the context of other events reported during the same runa localized message suitable for presenting to the user
an optional
NameInfo
that if defined, provides names for the suite and optionally the test in the context of which the information was providedan optional
Throwable
an optional
Formatter
that provides extra information that can be used by reporters in determining how to present this event to the userAn optional
Location
that provides information indicating where in the source code an event originated.an optional object that can be used to pass custom information to the reporter about the
AlertProvided
eventa name for the
Thread
about whose activity this event was reporteda
Long
indicating the time this event was reported, expressed in terms of the number of milliseconds since the standard base time known as "the epoch": January 1, 1970, 00:00:00 GMT