Companion object that facilitates the importing of DiagrammedAssertions members as
an alternative to mixing it in. One use case is to import DiagrammedAssertions members so you can use
them in the Scala interpreter:

final defasInstanceOf[T0]: T0

Assert that a boolean condition, described in Stringmessage, is true.
If the condition is true, this method returns normally.
Else, it throws TestFailedException with the
String obtained by invoking toString on the
specified clue as the exception's detail message and a
diagram showing expression values.

If multi-line Boolean is passed in, it will fallback to the macro implementation of Assertions
that does not contain diagram.

condition

the boolean condition to assert

clue

An objects whose toString method returns a message to include in a failure report.

Asserts that a given string snippet of code passes both the Scala parser and type checker.

Asserts that a given string snippet of code passes both the Scala parser and type checker.

You can use this to make sure a snippet of code compiles:

assertCompiles("val a: Int = 1")

Although assertCompiles is implemented with a macro that determines at compile time whether
the snippet of code represented by the passed string compiles, errors (i.e.,
snippets of code that do not compile) are reported as test failures at runtime.

Asserts that a given string snippet of code does not pass either the Scala parser or type checker.

Asserts that a given string snippet of code does not pass either the Scala parser or type checker.

Often when creating libraries you may wish to ensure that certain arrangements of code that
represent potential “user errors” do not compile, so that your library is more error resistant.
ScalaTest's Assertions trait includes the following syntax for that purpose:

assertDoesNotCompile("val a: String = \"a string")

Although assertDoesNotCompile is implemented with a macro that determines at compile time whether
the snippet of code represented by the passed string doesn't compile, errors (i.e.,
snippets of code that do compile) are reported as test failures at runtime.

Note that the difference between assertTypeError and assertDoesNotCompile is
that assertDoesNotCompile will succeed if the given code does not compile for any reason,
whereas assertTypeError will only succeed if the given code does not compile because of
a type error. If the given code does not compile because of a syntax error, for example, assertDoesNotCompile
will return normally but assertTypeError will throw a TestFailedException.

Assert that the value passed as expected equals the value passed as actual.

Assert that the value passed as expected equals the value passed as actual.
If the actual equals the expected
(as determined by ==), assertResult returns
normally. Else, if actual is not equal to expected, assertResult throws a
TestFailedException whose detail message includes the expected and actual values, as well as the String
obtained by invoking toString on the passed clue.

expected

the expected value

clue

An object whose toString method returns a message to include in a failure report.

Ensure that an expected exception is thrown by the passed function value.

Ensure that an expected exception is thrown by the passed function value. The thrown exception must be an instance of the
type specified by the type parameter of this method. This method invokes the passed
function. If the function throws an exception that's an instance of the specified type,
this method returns Succeeded. Else, whether the passed function returns normally
or completes abruptly with a different exception, this method throws TestFailedException.

Note that the type specified as this method's type parameter may represent any subtype of
AnyRef, not just Throwable or one of its subclasses. In
Scala, exceptions can be caught based on traits they implement, so it may at times make sense
to specify a trait that the intercepted exception's class must mix in. If a class instance is
passed for a type that could not possibly be used to catch an exception (such as String,
for example), this method will complete abruptly with a TestFailedException.

Also note that the difference between this method and intercept is that this method
does not return the expected exception, so it does not let you perform further assertions on
that exception. Instead, this method returns Succeeded, which means it can
serve as the last statement in an async- or safe-style suite. It also indicates to the reader
of the code that nothing further is expected about the thrown exception other than its type.
The recommended usage is to use assertThrows by default, intercept only when you
need to inspect the caught exception further.

f

the function value that should throw the expected exception

classTag

an implicit ClassTag representing the type of the specified
type parameter.

returns

the Succeeded singleton, if an exception of the expected type is thrown

Asserts that a given string snippet of code does not pass the Scala type checker, failing if the given
snippet does not pass the Scala parser.

Asserts that a given string snippet of code does not pass the Scala type checker, failing if the given
snippet does not pass the Scala parser.

Often when creating libraries you may wish to ensure that certain arrangements of code that
represent potential “user errors” do not compile, so that your library is more error resistant.
ScalaTest's Assertions trait includes the following syntax for that purpose:

assertTypeError("val a: String = 1")

Although assertTypeError is implemented with a macro that determines at compile time whether
the snippet of code represented by the passed string type checks, errors (i.e.,
snippets of code that do type check) are reported as test failures at runtime.

Note that the difference between assertTypeError and assertDoesNotCompile is
that assertDoesNotCompile will succeed if the given code does not compile for any reason,
whereas assertTypeError will only succeed if the given code does not compile because of
a type error. If the given code does not compile because of a syntax error, for example, assertDoesNotCompile
will return normally but assertTypeError will throw a TestFailedException.

Assume that a boolean condition, described in Stringmessage, is true.
If the condition is true, this method returns normally.
Else, it throws TestCanceledException with the
String obtained by invoking toString on the
specified clue as the exception's detail message and a
diagram showing expression values.

If multi-line Boolean is passed in, it will fallback to the macro implementation of Assertions
that does not contain diagram.

condition

the boolean condition to assume

clue

An objects whose toString method returns a message to include in a failure report.

final defgetClass(): Class[_]

defhashCode(): Int

Intercept and return an exception that's expected to
be thrown by the passed function value.

Intercept and return an exception that's expected to
be thrown by the passed function value. The thrown exception must be an instance of the
type specified by the type parameter of this method. This method invokes the passed
function. If the function throws an exception that's an instance of the specified type,
this method returns that exception. Else, whether the passed function returns normally
or completes abruptly with a different exception, this method throws TestFailedException.

Note that the type specified as this method's type parameter may represent any subtype of
AnyRef, not just Throwable or one of its subclasses. In
Scala, exceptions can be caught based on traits they implement, so it may at times make sense
to specify a trait that the intercepted exception's class must mix in. If a class instance is
passed for a type that could not possibly be used to catch an exception (such as String,
for example), this method will complete abruptly with a TestFailedException.

Also note that the difference between this method and assertThrows is that this method
returns the expected exception, so it lets you perform further assertions on
that exception. By contrast, the assertThrows method returns Succeeded, which means it can
serve as the last statement in an async- or safe-style suite. assertThrows also indicates to the reader
of the code that nothing further is expected about the thrown exception other than its type.
The recommended usage is to use assertThrows by default, intercept only when you
need to inspect the caught exception further.

f

the function value that should throw the expected exception

classTag

an implicit ClassTag representing the type of the specified
type parameter.

final defnotifyAll(): Unit

A pending test is one that has been given a name but is not yet implemented. The purpose of
pending tests is to facilitate a style of testing in which documentation of behavior is sketched
out before tests are written to verify that behavior (and often, the before the behavior of
the system being tested is itself implemented). Such sketches form a kind of specification of
what tests and functionality to implement later.

To support this style of testing, a test can be given a name that specifies one
bit of behavior required by the system being tested. The test can also include some code that
sends more information about the behavior to the reporter when the tests run. At the end of the test,
it can call method pending, which will cause it to complete abruptly with TestPendingException.
Because tests in ScalaTest can be designated as pending with TestPendingException, both the test name and any information
sent to the reporter when running the test can appear in the report of a test run. (In other words,
the code of a pending test is executed just like any other test.) However, because the test completes abruptly
with TestPendingException, the test will be reported as pending, to indicate
the actual test, and possibly the functionality it is intended to test, has not yet been implemented.

Note: This method always completes abruptly with a TestPendingException. Thus it always has a side
effect. Methods with side effects are usually invoked with parentheses, as in pending(). This
method is defined as a parameterless method, in flagrant contradiction to recommended Scala style, because it
forms a kind of DSL for pending tests. It enables tests in suites such as FunSuite or FunSpec
to be denoted by placing "(pending)" after the test name, as in:

test("that style rules are not laws") (pending)

Readers of the code see "pending" in parentheses, which looks like a little note attached to the test name to indicate
it is pending. Whereas "(pending()) looks more like a method call, "(pending)" lets readers
stay at a higher level, forgetting how it is implemented and just focusing on the intent of the programmer who wrote the code.

Execute the passed block of code, and if it completes abruptly, throw TestPendingException, else
throw TestFailedException.

Execute the passed block of code, and if it completes abruptly, throw TestPendingException, else
throw TestFailedException.

This method can be used to temporarily change a failing test into a pending test in such a way that it will
automatically turn back into a failing test once the problem originally causing the test to fail has been fixed.
At that point, you need only remove the pendingUntilFixed call. In other words, a
pendingUntilFixed surrounding a block of code that isn't broken is treated as a test failure.
The motivation for this behavior is to encourage people to remove pendingUntilFixed calls when
there are no longer needed.

This method facilitates a style of testing in which tests are written before the code they test. Sometimes you may
encounter a test failure that requires more functionality than you want to tackle without writing more tests. In this
case you can mark the bit of test code causing the failure with pendingUntilFixed. You can then write more
tests and functionality that eventually will get your production code to a point where the original test won't fail anymore.
At this point the code block marked with pendingUntilFixed will no longer throw an exception (because the
problem has been fixed). This will in turn cause pendingUntilFixed to throw TestFailedException
with a detail message explaining you need to go back and remove the pendingUntilFixed call as the problem orginally
causing your test code to fail has been fixed.

f

a block of code, which if it completes abruptly, should trigger a TestPendingException

You can use succeed to solve a type error when an async test
does not end in either Future[Assertion] or Assertion.
Because Assertion is a type alias for Succeeded.type,
putting succeed at the end of a test body (or at the end of a
function being used to map the final future of a test body) will solve
the type error.

final defwait(): Unit

final defwait(arg0: Long, arg1: Int): Unit

Definition Classes

AnyRef

Annotations

@throws(...)

final defwait(arg0: Long): Unit

Definition Classes

AnyRef

Annotations

@throws(...)

defwithClue[T](clue: Any)(fun: ⇒ T): T

Executes the block of code passed as the second parameter, and, if it
completes abruptly with a ModifiableMessage exception,
prepends the "clue" string passed as the first parameter to the beginning of the detail message
of that thrown exception, then rethrows it.

Executes the block of code passed as the second parameter, and, if it
completes abruptly with a ModifiableMessage exception,
prepends the "clue" string passed as the first parameter to the beginning of the detail message
of that thrown exception, then rethrows it. If clue does not end in a white space
character, one space will be added
between it and the existing detail message (unless the detail message is
not defined).

This method allows you to add more information about what went wrong that will be
reported when a test fails. Here's an example:

Deprecated Value Members

deftrap[T](f: ⇒ T): Throwable

Trap and return any thrown exception that would normally cause a ScalaTest test to fail, or create and return a new RuntimeException
indicating no exception is thrown.

Trap and return any thrown exception that would normally cause a ScalaTest test to fail, or create and return a new RuntimeException
indicating no exception is thrown.

This method is intended to be used in the Scala interpreter to eliminate large stack traces when trying out ScalaTest assertions and
matcher expressions. It is not intended to be used in regular test code. If you want to ensure that a bit of code throws an expected
exception, use intercept, not trap. Here's an example interpreter session without trap:

scala> import org.scalatest._
import org.scalatest._
scala> import Matchers._
import Matchers._
scala> val x = 12
a: Int = 12
scala> x shouldEqual 13
org.scalatest.exceptions.TestFailedException: 12 did not equal 13
at org.scalatest.Assertions$class.newAssertionFailedException(Assertions.scala:449)
at org.scalatest.Assertions$.newAssertionFailedException(Assertions.scala:1203)
at org.scalatest.Assertions$AssertionsHelper.macroAssertTrue(Assertions.scala:417)
at .<init>(<console>:15)
at .<clinit>(<console>)
at .<init>(<console>:7)
at .<clinit>(<console>)
at $print(<console>)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at scala.tools.nsc.interpreter.IMain$ReadEvalPrint.call(IMain.scala:731)
at scala.tools.nsc.interpreter.IMain$Request.loadAndRun(IMain.scala:980)
at scala.tools.nsc.interpreter.IMain.loadAndRunReq$1(IMain.scala:570)
at scala.tools.nsc.interpreter.IMain.interpret(IMain.scala:601)
at scala.tools.nsc.interpreter.IMain.interpret(IMain.scala:565)
at scala.tools.nsc.interpreter.ILoop.reallyInterpret$1(ILoop.scala:745)
at scala.tools.nsc.interpreter.ILoop.interpretStartingWith(ILoop.scala:790)
at scala.tools.nsc.interpreter.ILoop.command(ILoop.scala:702)
at scala.tools.nsc.interpreter.ILoop.processLine$1(ILoop.scala:566)
at scala.tools.nsc.interpreter.ILoop.innerLoop$1(ILoop.scala:573)
at scala.tools.nsc.interpreter.ILoop.loop(ILoop.scala:576)
at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply$mcZ$sp(ILoop.scala:867)
at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply(ILoop.scala:822)
at scala.tools.nsc.interpreter.ILoop$$anonfun$process$1.apply(ILoop.scala:822)
at scala.tools.nsc.util.ScalaClassLoader$.savingContextLoader(ScalaClassLoader.scala:135)
at scala.tools.nsc.interpreter.ILoop.process(ILoop.scala:822)
at scala.tools.nsc.MainGenericRunner.runTarget$1(MainGenericRunner.scala:83)
at scala.tools.nsc.MainGenericRunner.process(MainGenericRunner.scala:96)
at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:105)
at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)

That's a pretty tall stack trace. Here's what it looks like when you use trap:

Much less clutter. Bear in mind, however, that if no exception is thrown by the
passed block of code, the trap method will create a new NormalResult
(a subclass of Throwable made for this purpose only) and return that. If the result was the Unit value, it
will simply say that no exception was thrown:

Although you can access the result value from the NormalResult, its type is Any and therefore not
very convenient to use. It is not intended that trap be used in test code. The sole intended use case for trap is decluttering
Scala interpreter sessions by eliminating stack traces when executing assertion and matcher expressions.