This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for Matchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for Matchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for Matchers for an overview of
the matchers DSL.
This class is used in conjunction with an implicit conversion to enable must methods to
be invoked on objects of type Any.
Helper class used by code generated by the assert macro.
Helper class used by code generated by the assert macro.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for Matchers for an overview of
the matchers DSL.
This class is used as the result of an implicit conversion from class Symbol, to enable symbols to be
used in have ('author ("Dickens")) syntax. The name of the implicit conversion method is
convertSymbolToHavePropertyMatcherGenerator.
Class HavePropertyMatcherGenerator's primary constructor takes a Symbol. The
apply method uses reflection to find and access a property that has the name specified by the
Symbol passed to the constructor, so it can determine if the property has the expected value
passed to apply.
If the symbol passed is 'title, for example, the apply method
will use reflection to look for a public Java field named
"title", a public method named "title", or a public method named "getTitle".
If a method, it must take no parameters. If multiple candidates are found,
the apply method will select based on the following algorithm:
| Field | Method | "get" Method | Result |
|---|---|---|---|
Throws TestFailedException, because no candidates found | |||
getTitle() | Invokes getTitle() | ||
title() | Invokes title() | ||
title() | getTitle() | Invokes title() (this can occur when BeanProperty annotation is used) | |
title | Accesses field title | ||
title | getTitle() | Invokes getTitle() | |
title | title() | Invokes title() | |
title | title() | getTitle() | Invokes title() (this can occur when BeanProperty annotation is used) |
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for Matchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for Matchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for Matchers for an overview of
the matchers DSL.
This class is used in conjunction with an implicit conversion to enable withGroup and withGroups methods to
be invoked on Regexs.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for Matchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for InspectorsMatchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for InspectorsMatchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for InspectorsMatchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for InspectorsMatchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for InspectorsMatchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for Matchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for InspectorsMatchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for Matchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for Matchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for Matchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for InspectorsMatchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for Matchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for InspectorsMatchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for InspectorsMatchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for Matchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for Matchers for an overview of
the matchers DSL.
This class is used in conjunction with an implicit conversion to enable must methods to
be invoked on Strings.
This class supports the syntax of FlatSpec, WordSpec, fixture.FlatSpec,
and fixture.WordSpec.
This class supports the syntax of FlatSpec, WordSpec, fixture.FlatSpec,
and fixture.WordSpec.
This class is used in conjunction with an implicit conversion to enable must methods to
be invoked on Strings.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for Matchers for an overview of
the matchers DSL.
This class is part of the ScalaTest matchers DSL.
This class is part of the ScalaTest matchers DSL. Please see the documentation for Matchers for an overview of
the matchers DSL.
This method enables the following syntax:
This method enables the following syntax:
num must (not be < (10) and not be > (17)) ^
This method enables the following syntax:
This method enables the following syntax:
num must (not be <= (10) and not be > (17)) ^
This method enables the following syntax:
This method enables the following syntax:
num must (not be > (10) and not be < (7)) ^
This method enables the following syntax:
This method enables the following syntax:
num must (not be >= (10) and not be < (7)) ^
This method enables the following syntax:
This method enables the following syntax:
a [RuntimeException] must be thrownBy { ... }
^
This field enables the following syntax:
This field enables the following syntax:
badBook must not be a ('goodRead)
^
This method enables the following syntax for String:
This method enables the following syntax for String:
all(str) must fullymatch regex ("Hel*o world".r)
^
This method enables the following syntax for java.util.Map:
This method enables the following syntax for java.util.Map:
all(jmap) must fullymatch regex ("Hel*o world".r)
^
This method enables the following syntax:
This method enables the following syntax:
all(xs) must fullymatch regex ("Hel*o world".r)
^
This method enables the following syntax:
This method enables the following syntax:
List(1, 2, 3) must contain (allElementsOf(1, 2)) ^
This method enables the following syntax:
This method enables the following syntax:
List(1, 2, 3) must contain (allOf(1, 2)) ^
This method enables the following syntax:
This method enables the following syntax:
an [Exception] must be thrownBy { ... }
^
This field enables the following syntax:
This field enables the following syntax:
badBook must not be an (excellentRead)
^
Assert that a boolean condition, described in String
message, is true.
Assert that a boolean condition, described in String
message, is true.
If the condition is true, this method returns normally.
Else, it throws TestFailedException with a helpful error message
appended with the String obtained by invoking toString on the
specified clue as the exception's detail message.
This method is implemented in terms of a Scala macro that will generate a more helpful error message for expressions of this form:
At this time, any other form of expression will just get a TestFailedException with message saying the given
expression was false. In the future, we will enhance this macro to give helpful error messages in more situations.
In ScalaTest 2.0, however, this behavior was sufficient to allow the === that returns Boolean
to be the default in tests. This makes === consistent between tests and production
code.
the boolean condition to assert
An objects whose toString method returns a message to include in a failure report.
NullArgumentException if message is null.
TestFailedException if the condition is false.
Assert that a boolean condition is true.
Assert that a boolean condition is true.
If the condition is true, this method returns normally.
Else, it throws TestFailedException.
This method is implemented in terms of a Scala macro that will generate a more helpful error message for expressions of this form:
At this time, any other form of expression will get a TestFailedException with message saying the given
expression was false. In the future, we will enhance this macro to give helpful error messages in more situations.
In ScalaTest 2.0, however, this behavior was sufficient to allow the === that returns Boolean
to be the default in tests. This makes === consistent between tests and production
code.
the boolean condition to assert
TestFailedException if the condition is false.
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.
the snippet of code that should compile
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.
the snippet of code that should not type check
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 value equals the expected value
(as determined by ==), assertResult returns
normally. Else, assertResult throws a
TestFailedException whose detail message includes the expected and actual values.
the expected value
the actual value, which should equal the passed expected value
TestFailedException if the passed actual value does not equal the passed expected value.
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.
the expected value
An object whose toString method returns a message to include in a failure report.
the actual value, which should equal the passed expected value
TestFailedException if the passed actual value does not equal the passed expected value.
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.
the function value that should throw the expected exception
an implicit ClassTag representing the type of the specified
type parameter.
the Succeeded singleton, if an exception of the expected type is thrown
TestFailedException if the passed function does not complete abruptly with an exception
that's an instance of the specified type.
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.
the snippet of code that should not type check
Helper instance used by code generated by macro assertion.
Helper instance used by code generated by macro assertion.
Assume that a boolean condition, described in String
message, is true.
Assume that a boolean condition, described in String
message, is true.
If the condition is true, this method returns normally.
Else, it throws TestCanceledException with a helpful error message
appended with String obtained by invoking toString on the
specified clue as the exception's detail message.
This method is implemented in terms of a Scala macro that will generate a more helpful error message for expressions of this form:
At this time, any other form of expression will just get a TestCanceledException with message saying the given
expression was false. In the future, we will enhance this macro to give helpful error messages in more situations.
In ScalaTest 2.0, however, this behavior was sufficient to allow the === that returns Boolean
to be the default in tests. This makes === consistent between tests and production
code.
the boolean condition to assume
An objects whose toString method returns a message to include in a failure report.
NullArgumentException if message is null.
TestCanceledException if the condition is false.
Assume that a boolean condition is true.
Assume that a boolean condition is true.
If the condition is true, this method returns normally.
Else, it throws TestCanceledException.
This method is implemented in terms of a Scala macro that will generate a more helpful error message for expressions of this form:
At this time, any other form of expression will just get a TestCanceledException with message saying the given
expression was false. In the future, we will enhance this macro to give helpful error messages in more situations.
In ScalaTest 2.0, however, this behavior was sufficient to allow the === that returns Boolean
to be the default in tests. This makes === consistent between tests and production
code.
the boolean condition to assume
TestCanceledException if the condition is false.
This method enables the following syntax for String:
This method enables the following syntax for String:
atLeast(1, str) must fullymatch regex ("Hel*o world".r) ^
This method enables the following syntax for java.util.Map:
This method enables the following syntax for java.util.Map:
atLeast(1, jmap) must fullymatch regex ("Hel*o world".r) ^
This method enables the following syntax:
This method enables the following syntax:
atLeast(1, xs) must fullymatch regex ("Hel*o world".r) ^
This method enables the following syntax:
This method enables the following syntax:
List(1, 2, 3) must contain (atLeastOneElementOf (List(1, 2))) ^
This method enables the following syntax:
This method enables the following syntax:
List(1, 2, 3) must contain (atLeastOneOf(1, 2)) ^
This method enables the following syntax for String:
This method enables the following syntax for String:
atMost(3, str) must fullymatch regex ("Hel*o world".r) ^
This method enables the following syntax for java.util.Map:
This method enables the following syntax for java.util.Map:
atMost(3, jmap) must fullymatch regex ("Hel*o world".r) ^
This method enables the following syntax:
This method enables the following syntax:
atMost(3, xs) must fullymatch regex ("Hel*o world".r) ^
This method enables the following syntax:
This method enables the following syntax:
List(1, 2, 3) must contain (atMostOneElementOf (List(1, 2))) ^
This method enables the following syntax:
This method enables the following syntax:
List(1, 2, 3) must contain (atMostOneOf(1, 2)) ^
This field enables syntax such as the following:
This field enables syntax such as the following:
obj should (be theSameInstanceAs (string) and be theSameInstanceAs (string))
^
This method enables the following syntax for String:
This method enables the following syntax for String:
between(1, 3, str) must fullymatch regex ("Hel*o world".r) ^
This method enables the following syntax for java.util.Map:
This method enables the following syntax for java.util.Map:
between(1, 3, jmap) must fullymatch regex ("Hel*o world".r) ^
This method enables the following syntax:
This method enables the following syntax:
between(1, 3, xs) must fullymatch regex ("Hel*o world".r) ^
Throws TestCanceledException, with the passed
Throwable cause, to indicate a test failed.
Throws TestCanceledException, with the passed
Throwable cause, to indicate a test failed.
The getMessage method of the thrown TestCanceledException
will return cause.toString.
a Throwable that indicates the cause of the cancellation.
NullArgumentException if cause is null
Throws TestCanceledException, with the passed
String message as the exception's detail
message and Throwable cause, to indicate a test failed.
Throws TestCanceledException, with the passed
String message as the exception's detail
message and Throwable cause, to indicate a test failed.
A message describing the failure.
A Throwable that indicates the cause of the failure.
NullArgumentException if message or cause is null
Throws TestCanceledException, with the passed
String message as the exception's detail
message, to indicate a test was canceled.
Throws TestCanceledException, with the passed
String message as the exception's detail
message, to indicate a test was canceled.
A message describing the cancellation.
NullArgumentException if message is null
Throws TestCanceledException to indicate a test was canceled.
Throws TestCanceledException to indicate a test was canceled.
This field enables the following syntax:
This field enables the following syntax:
"val a: String = 1" shouldNot compile
^
This field enables syntax such as the following:
This field enables syntax such as the following:
list should (contain ('a') and have length (7)) ^
This implicit conversion method converts a Symbol to a
HavePropertyMatcherGenerator, to enable the symbol to be used with the have ('author ("Dickens")) syntax.
This implicit conversion method converts a Symbol to a
HavePropertyMatcherGenerator, to enable the symbol to be used with the have ('author ("Dickens")) syntax.
Implicitly converts an object of type T to a AnyMustWrapper[T],
to enable must methods to be invokable on that object.
Implicitly converts an object of type T to a AnyMustWrapper[T],
to enable must methods to be invokable on that object.
Implicitly converts an object of type scala.util.matching.Regex to a RegexWrapper,
to enable withGroup and withGroups methods to be invokable on that object.
Implicitly converts an object of type scala.util.matching.Regex to a RegexWrapper,
to enable withGroup and withGroups methods to be invokable on that object.
Implicitly converts an object of type java.lang.String to a StringMustWrapper,
to enable must methods to be invokable on that object.
Implicitly converts an object of type java.lang.String to a StringMustWrapper,
to enable must methods to be invokable on that object.
Implicitly converts an object of type String to a StringMustWrapper,
to enable must methods to be invokable on that object.
Implicitly converts an object of type String to a StringMustWrapper,
to enable must methods to be invokable on that object.
This field enables the following syntax:
This field enables the following syntax:
seq should be (defined)
^
This method enables the following syntax:
This method enables the following syntax:
list must (not be definedAt (7) and not be definedAt (9)) ^
This field enables the following syntax:
This field enables the following syntax:
list should be (empty)
^
This field enables syntax such as the following:
This field enables syntax such as the following:
string should (endWith ("ago") and include ("score")) ^
This method enables syntax such as the following:
This method enables syntax such as the following:
result must equal (null)
^
This method enables syntax such as the following:
This method enables syntax such as the following:
result must equal (100 +- 1) ^
This method enables the following syntax:
This method enables the following syntax:
result should equal (7)
^
The left should equal (right) syntax works by calling == on the left
value, passing in the right value, on every type except arrays. If both left and right are arrays, deep
will be invoked on both left and right before comparing them with ==. Thus, even though this expression
will yield false, because Array's equals method compares object identity:
Array(1, 2) == Array(1, 2) // yields false
The following expression will not result in a TestFailedException, because ScalaTest will compare
the two arrays structurally, taking into consideration the equality of the array's contents:
Array(1, 2) should equal (Array(1, 2)) // succeeds (i.e., does not throw TestFailedException)
If you ever do want to verify that two arrays are actually the same object (have the same identity), you can use the
be theSameInstanceAs syntax.
This method enables the following syntax for String:
This method enables the following syntax for String:
every(str) must fullymatch regex ("Hel*o world".r)
^
This method enables the following syntax for java.util.Map:
This method enables the following syntax for java.util.Map:
every(jmap) must fullymatch regex ("Hel*o world".r)
^
This method enables the following syntax:
This method enables the following syntax:
every(xs) must fullymatch regex ("Hel*o world".r)
^
This method enables the following syntax for String:
This method enables the following syntax for String:
exactly(str) must fullymatch regex ("Hel*o world".r)
^
This method enables the following syntax for java.util.Map:
This method enables the following syntax for java.util.Map:
exactly(jmap) must fullymatch regex ("Hel*o world".r)
^
This method enables the following syntax:
This method enables the following syntax:
exactly(xs) must fullymatch regex ("Hel*o world".r)
^
This field enables the following syntax:
This field enables the following syntax:
file should exist
^
Throws TestFailedException, with the passed
Throwable cause, to indicate a test failed.
Throws TestFailedException, with the passed
Throwable cause, to indicate a test failed.
The getMessage method of the thrown TestFailedException
will return cause.toString.
a Throwable that indicates the cause of the failure.
NullArgumentException if cause is null
Throws TestFailedException, with the passed
String message as the exception's detail
message and Throwable cause, to indicate a test failed.
Throws TestFailedException, with the passed
String message as the exception's detail
message and Throwable cause, to indicate a test failed.
A message describing the failure.
A Throwable that indicates the cause of the failure.
NullArgumentException if message or cause is null
Throws TestFailedException, with the passed
String message as the exception's detail
message, to indicate a test failed.
Throws TestFailedException, with the passed
String message as the exception's detail
message, to indicate a test failed.
A message describing the failure.
NullArgumentException if message is null
Throws TestFailedException to indicate a test failed.
Throws TestFailedException to indicate a test failed.
This field enables syntax such as the following:
This field enables syntax such as the following:
string should (fullyMatch regex ("Hel*o, wor.d") and not have length (99)) ^
This field enables syntax such as the following:
This field enables syntax such as the following:
list should (have length (3) and not contain ('a')) ^
This method enables the following syntax:
This method enables the following syntax:
List(1, 2, 3) must contain (inOrder(1, 2)) ^
This method enables the following syntax:
This method enables the following syntax:
List(1, 2, 3) must contain (inOrderElementsOf List(1, 2)) ^
This method enables the following syntax:
This method enables the following syntax:
List(1, 2, 3) must contain (inOrderOnly(1, 2)) ^
This field enables syntax such as the following:
This field enables syntax such as the following:
string should (include ("hope") and not startWith ("no")) ^
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.
the function value that should throw the expected exception
an implicit ClassTag representing the type of the specified
type parameter.
the intercepted exception, if it is of the expected type
TestFailedException if the passed function does not complete abruptly with an exception
that's an instance of the specified type.
This field enables the following syntax:
This field enables the following syntax:
map must not contain key (10)
^
This field enables the following syntax:
This field enables the following syntax:
"hi" should not have length (3) ^
This field enables the following syntax:
This field enables the following syntax:
result should matchPattern { case Person("Bob", _) => }
^
This method enables the following syntax:
This method enables the following syntax:
exception must not have message ("file not found")
^
This method enables the following syntax for String:
This method enables the following syntax for String:
no(str) must fullymatch regex ("Hel*o world".r)
^
This method enables the following syntax for java.util.Map:
This method enables the following syntax for java.util.Map:
no(jmap) must fullymatch regex ("Hel*o world".r)
^
This method enables the following syntax:
This method enables the following syntax:
no(xs) must fullymatch regex ("Hel*o world".r)
^
This method enables the following syntax:
This method enables the following syntax:
List(1, 2, 3) must contain (noElementsOf List(1, 2)) ^
This field enables the following syntax:
This field enables the following syntax:
noException should be thrownBy ^
This method enables the following syntax:
This method enables the following syntax:
List(1, 2, 3) must contain (noneOf(1, 2)) ^
This field enables syntax like the following:
This field enables syntax like the following:
myFile should (not be an (directory) and not have ('name ("foo.bar"))) ^
This method enables syntax such as the following:
This method enables syntax such as the following:
book must have (message ("A TALE OF TWO CITIES") (of [Book]), title ("A Tale of Two Cities")) ^
This method enables the following syntax:
This method enables the following syntax:
List(1, 2, 3) must contain (oneElementOf (List(1, 2))) ^
This method enables the following syntax:
This method enables the following syntax:
List(1, 2, 3) must contain (oneOf(1, 2)) ^
This method enables the following syntax:
This method enables the following syntax:
List(1, 2, 3) must contain (only(1, 2)) ^
Throws TestPendingException to indicate a test is pending.
Throws TestPendingException to indicate a test is pending.
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.
a block of code, which if it completes abruptly, should trigger a TestPendingException
TestPendingException if the passed block of code completes abruptly with an Exception or AssertionError
This field enables the following syntax:
This field enables the following syntax:
file should be (readable)
^
This field enables the following syntax:
This field enables the following syntax:
"eight" must not fullyMatch regex ("""(-)?(\d+)(\.\d*)?""".r) ^
This field enables the following syntax:
This field enables the following syntax:
set should not have size (3)
^
This field enables the following syntax:
This field enables the following syntax:
seq should be (sorted)
^
This field enables syntax such as the following:
This field enables syntax such as the following:
string should (startWith ("Four") and include ("year")) ^
The Succeeded singleton.
The Succeeded singleton.
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.
This method enables the following syntax:
This method enables the following syntax:
the [FileNotFoundException] must be thrownBy { ... }
^
This method enables the following syntax:
This method enables the following syntax:
List(1, 2, 3) must contain (theSameElementsAs(List(1, 2, 3))) ^
This method enables the following syntax:
This method enables the following syntax:
List(1, 2, 3) must contain (theSameElementsInOrderAs(List(1, 2))) ^
This field enables the following syntax:
This field enables the following syntax:
oneString must not be theSameInstanceAs (anotherString)
^
This method enables the following syntax:
This method enables the following syntax:
a [RuntimeException] must be thrownBy {...}
^
This field enables the following syntax:
This field enables the following syntax:
"val a: String = 1" shouldNot typeCheck
^
This field enables the following syntax:
This field enables the following syntax:
map must not contain value (10)
^
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:
withClue("(Employee's name was: " + employee.name + ")") { intercept[IllegalArgumentException] { employee.getTask(-1) } }
If an invocation of intercept completed abruptly with an exception, the resulting message would be something like:
(Employee's name was Bob Jones) Expected IllegalArgumentException to be thrown, but no exception was thrown
NullArgumentException if the passed clue is null
This field enables the following syntax:
This field enables the following syntax:
file should be (writable)
^
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:
scala> trap { x shouldEqual 13 }
res1: Throwable = org.scalatest.exceptions.TestFailedException: 12 did not equal 13
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:
scala> trap { x shouldEqual 12 }
res2: Throwable = No exception was thrown.
If the passed block of code results in a value other than Unit, the NormalResult's toString will print the value:
scala> trap { "Dude!" }
res3: Throwable = No exception was thrown. Instead, result was: "Dude!"
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.
The trap method is no longer needed for demos in the REPL, which now abreviates stack traces, and will be removed in a future version of ScalaTest
Trait that provides a domain specific language (DSL) for expressing assertions in tests using the word
must.For example, if you mix
Matchersinto a suite class, you can write an equality assertion in that suite like this:result must equal (3)Here
resultis a variable, and can be of any type. If the object is anIntwith the value 3, execution will continue (i.e., the expression will result in the unit value,()). Otherwise, aTestFailedExceptionwill be thrown with a detail message that explains the problem, such as"7 did not equal 3". ThisTestFailedExceptionwill cause the test to fail.Here is a table of contents for this documentation:
Booleanproperties withbeBeMatchersStrings andArrays as collectionsandandorOptionshavelengthandsizewithHavePropertyMatchersTrait
MustMatchersis an alternative toMatchersthat provides the exact same meaning, syntax, and behavior asMatchers, but uses the verbmustinstead ofshould. The two traits differ only in the English semantics of the verb:shouldis informal, making the code feel like conversation between the writer and the reader;mustis more formal, making the code feel more like a written specification.Checking equality with matchers
ScalaTest matchers provides five different ways to check equality, each designed to address a different need. They are:
The “
leftmustequal(right)” syntax requires anorg.scalactic.Equality[L]to be provided (either implicitly or explicitly), whereLis the left-hand type on whichmustis invoked. In the "leftmustequal(right)" case, for example,Lis the type ofleft. Thus ifleftis typeInt, the "leftmustequal(right)" statement would require anEquality[Int].By default, an implicit
Equality[T]instance is available for any typeT, in which equality is implemented by simply invoking==on theleftvalue, passing in therightvalue, with special treatment for arrays. If eitherleftorrightis an array,deepwill be invoked on it before comparing with ==. Thus, the following expression will yield false, becauseArray'sequalsmethod compares object identity:The next expression will by default not result in a
TestFailedException, because defaultEquality[Array[Int]]compares the two arrays structurally, taking into consideration the equality of the array's contents:If you ever do want to verify that two arrays are actually the same object (have the same identity), you can use the
be theSameInstanceAssyntax, described below.You can customize the meaning of equality for a type when using "
mustequal," "must===," ormustEqualsyntax by defining implicitEqualityinstances that will be used instead of defaultEquality. You might do this to normalize types before comparing them with==, for instance, or to avoid calling the==method entirely, such as if you want to compareDoubles with a tolerance. For an example, see the main documentation of traitEquality.You can always supply implicit parameters explicitly, but in the case of implicit parameters of type
Equality[T], Scalactic provides a simple "explictly" DSL. For example, here's how you could explicitly supply anEquality[String]instance that normalizes both left and right sides (which must be strings), by transforming them to lowercase:scala> import org.scalatest.MustMatchers._ import org.scalatest.MustMatchers._ scala> import org.scalactic.Explicitly._ import org.scalactic.Explicitly._ scala> import org.scalactic.StringNormalizations._ import org.scalactic.StringNormalizations._ scala> "Hi" must equal ("hi") (after being lowerCased)The
afterbeinglowerCasedexpression results in anEquality[String], which is then passed explicitly as the second curried parameter toequal. For more information on the explictly DSL, see the main documentation for traitExplicitly.The "
mustbe" andmustBesyntax do not take anEquality[T]and can therefore not be customized. They always use the default approach to equality described above. As a result, "mustbe" andmustBewill likely be the fastest-compiling matcher syntax for equality comparisons, since the compiler need not search for an implicitEquality[T]each time.The
must===syntax (and its complement,must!==) can be used to enforce type constraints at compile-time between the left and right sides of the equality comparison. Here's an example:scala> import org.scalatest.MustMatchers._ import org.scalatest.MustMatchers._ scala> import org.scalactic.TypeCheckedTripleEquals._ import org.scalactic.TypeCheckedTripleEquals._ scala> Some(2) must === (2) <console>:17: error: types Some[Int] and Int do not adhere to the equality constraint selected for the === and !== operators; the missing implicit parameter is of type org.scalactic.CanEqual[Some[Int],Int] Some(2) must === (2) ^By default, the "
Some(2)must===(2)" statement would fail at runtime. By mixing in the equality constraints provided byTypeCheckedTripleEquals, however, the statement fails to compile. For more information and examples, see the main documentation for traitTypeCheckedTripleEquals.Checking size and length
You can check the size or length of any type of object for which it makes sense. Here's how checking for length looks:
result must have length 3Size is similar:
result must have size 10The
lengthsyntax can be used withString,Array, anyscala.collection.GenSeq, anyjava.util.List, and any typeTfor which an implicitLength[T]type class is available in scope. Similarly, thesizesyntax can be used withArray, anyscala.collection.GenTraversable, anyjava.util.Collection, anyjava.util.Map, and any typeTfor which an implicitSize[T]type class is available in scope. You can enable thelengthorsizesyntax for your own arbitrary types, therefore, by definingLengthorSizetype classes for those types.In addition, the
lengthsyntax can be used with any object that has a field or method namedlengthor a method namedgetLength. Similarly, thesizesyntax can be used with any object that has a field or method namedsizeor a method namedgetSize. The type of alengthorsizefield, or return type of a method, must be eitherIntorLong. Any such method must take no parameters. (The Scala compiler will ensure at compile time that the object on whichmustis being invoked has the appropriate structure.)Checking strings
You can check for whether a string starts with, ends with, or includes a substring like this:
You can check for whether a string starts with, ends with, or includes a regular expression, like this:
And you can check whether a string fully matches a regular expression, like this:
string must fullyMatch regex """(-)?(\d+)(\.\d*)?"""The regular expression passed following the
regextoken can be either aStringor ascala.util.matching.Regex.With the
startWith,endWith,include, andfullyMatchtokens can also be used with an optional specification of required groups, like this:You can check whether a string is empty with
empty:You can also use most of ScalaTest's matcher syntax for collections on
Stringby treating theStrings as collections of characters. For examples, see theStrings andArrays as collections section below.Greater and less than
You can check whether any type for which an implicit
Ordering[T]is available is greater than, less than, greater than or equal, or less than or equal to a value of typeT. The syntax is:Checking
Booleanproperties withbeIf an object has a method that takes no parameters and returns boolean, you can check it by placing a
Symbol(afterbe) that specifies the name of the method (excluding an optional prefix of "is"). A symbol literal in Scala begins with a tick mark and ends at the first non-identifier character. Thus,'traversableAgainresults in aSymbolobject at runtime, as does'completedand'file. Here's an example:iter mustBe 'traversableAgainGiven this code, ScalaTest will use reflection to look on the object referenced from
emptySetfor a method that takes no parameters and results inBoolean, with either the nameemptyorisEmpty. If found, it will invoke that method. If the method returnstrue, execution will continue. But if it returnsfalse, aTestFailedExceptionwill be thrown that will contain a detail message, such as:This
besyntax can be used with any reference (AnyRef) type. If the object does not have an appropriately named predicate method, you'll get aTestFailedExceptionat runtime with a detailed message that explains the problem. (For the details on how a field or method is selected during this process, see the documentation forBeWord.)If you think it reads better, you can optionally put
aoranafterbe. For example,java.io.Filehas two predicate methods,isFileandisDirectory. Thus with aFileobject namedtemp, you could write:temp must be a 'fileOr, given
java.awt.event.KeyEventhas a methodisActionKeythat takes no arguments and returnsBoolean, you could assert that aKeyEventis an action key with:keyEvent must be an 'actionKeyIf you prefer to check
Booleanproperties in a type-safe manner, you can use aBePropertyMatcher. This would allow you to write expressions such as:These expressions would fail to compile if
mustis used on an inappropriate type, as determined by the type parameter of theBePropertyMatcherbeing used. (For example,filein this example would likely be of typeBePropertyMatcher[java.io.File]. If used with an appropriate type, such an expression will compile and at run time theBooleanproperty method or field will be accessed directly; i.e., no reflection will be used. See the documentation forBePropertyMatcherfor more information.Using custom
BeMatchersIf you want to create a new way of using
be, which doesn't map to an actual property on the type you care about, you can create aBeMatcher. You could use this, for example, to createBeMatcher[Int]calledodd, which would match any oddInt, andeven, which would match any evenInt. Given this pair ofBeMatchers, you could check whether anIntwas odd or even with expressions like:For more information, see the documentation for
BeMatcher.Checking object identity
If you need to check that two references refer to the exact same object, you can write:
Checking an object's class
If you need to check that an object is an instance of a particular class or trait, you can supply the type to “
bea” or “bean”:Because type parameters are erased on the JVM, we recommend you insert an underscore for any type parameters when using this syntax. Both of the following test only that the result is an instance of
List[_], because at runtime the type parameter has been erased:Checking numbers against a range
Often you may want to check whether a number is within a range. You can do that using the
+-operator, like this:Any of these expressions will cause a
TestFailedExceptionto be thrown if the floating point value,sevenDotOhis outside the range6.7to7.1. You can use+-with any typeTfor which an implicitNumeric[T]exists, such as integral types:Checking for emptiness
You can check whether an object is "empty", like this:
The
emptytoken can be used with any typeLfor which an implicitEmptiness[L]exists. TheEmptinesscompanion object provides implicits forGenTraversable[E],java.util.Collection[E],java.util.Map[K, V],String,Array[E], andOption[E]. In addition, theEmptinesscompanion object provides structural implicits for types that declare anisEmptymethod that returns aBoolean. Here are some examples:scala> import org.scalatest.MustMatchers._ import org.scalatest.MustMatchers._ scala> List.empty mustBe empty scala> None mustBe empty scala> Some(1) must not be empty scala> "" mustBe empty scala> new java.util.HashMap[Int, Int] mustBe empty scala> new { def isEmpty = true} mustBe empty scala> Array(1, 2, 3) must not be emptyWorking with "containers"
You can check whether a collection contains a particular element like this:
traversable must contain ("five")The
containsyntax shown above can be used with any typeCthat has a "containing" nature, evidenced by an implicitorg.scalatest.enablers.Containing[L], whereLis left-hand type on whichmustis invoked. In theContainingcompanion object, implicits are provided for typesGenTraversable[E],java.util.Collection[E],java.util.Map[K, V],String,Array[E], andOption[E]. Here are some examples:scala> import org.scalatest.MustMatchers._ import org.scalatest.MustMatchers._ scala> List(1, 2, 3) must contain (2) scala> Map('a' -> 1, 'b' -> 2, 'c' -> 3) must contain ('b' -> 2) scala> Set(1, 2, 3) must contain (2) scala> Array(1, 2, 3) must contain (2) scala> "123" must contain ('2') scala> Some(2) must contain (2)ScalaTest's implicit methods that provide the
Containing[L]type classes require anEquality[E], whereEis an element type. For example, to obtain aContaining[Array[Int]]you must supply anEquality[Int], either implicitly or explicitly. Thecontainsyntax uses thisEquality[E]to determine containership. Thus if you want to change how containership is determined for an element typeE, place an implicitEquality[E]in scope or use the explicitly DSL. Although the implicit parameter required for thecontainsyntax is of typeContaining[L], implicit conversions are provided in theContainingcompanion object fromEquality[E]to the various types of containers ofE. Here's an example:scala> import org.scalatest.MustMatchers._ import org.scalatest.MustMatchers._ scala> List("Hi", "Di", "Ho") must contain ("ho") org.scalatest.exceptions.TestFailedException: List(Hi, Di, Ho) did not contain element "ho" at ... scala> import org.scalactic.Explicitly._ import org.scalactic.Explicitly._ scala> import org.scalactic.StringNormalizations._ import org.scalactic.StringNormalizations._ scala> (List("Hi", "Di", "Ho") must contain ("ho")) (after being lowerCased)Note that when you use the explicitly DSL with
containyou need to wrap the entirecontainexpression in parentheses, as shown here.(List("Hi", "Di", "Ho") must contain ("ho")) (after being lowerCased) ^ ^In addition to determining whether an object contains another object, you can use
containto make other determinations. For example, thecontainoneOfsyntax ensures that one and only one of the specified elements are contained in the containing object:Note that if multiple specified elements appear in the containing object,
oneOfwill fail:scala> List(1, 2, 3) must contain oneOf (2, 3, 4) org.scalatest.exceptions.TestFailedException: List(1, 2, 3) did not contain one (and only one) of (2, 3, 4) at ...If you really want to ensure one or more of the specified elements are contained in the containing object, use
atLeastOneOf, described below, instead ofoneOf. Keep in mind,oneOfmeans "exactly one of."Note also that with any
containsyntax, you can place custom implicitEquality[E]instances in scope to customize how containership is determined, or use the explicitly DSL. Here's an example:If you have a collection of elements that you'd like to use in a "one of" comparison, you can use "oneElementOf," like this:
The
containnoneOfsyntax does the opposite ofoneOf: it ensures none of the specified elements are contained in the containing object:If you have a collection of elements that you'd like to use in a "none of" comparison, you can use "noElementsOf," like this:
Working with "aggregations"
As mentioned, the "
contain," "containoneOf," and "containnoneOf" syntax requires aContaining[L]be provided, whereLis the left-hand type. Othercontainsyntax, which will be described in this section, requires anAggregating[L]be provided, where againLis the left-hand type. (AnAggregating[L]instance defines the "aggregating nature" of a typeL.) The reason, essentially, is thatcontainsyntax that makes sense forOptionis enabled byContaining[L], whereas syntax that does not make sense forOptionis enabled byAggregating[L]. For example, it doesn't make sense to assert that anOption[Int]contains all of a set of integers, as it could only ever contain one of them. But this does make sense for a type such asList[Int]that can aggregate zero to many integers.The
Aggregatingcompanion object provides implicit instances ofAggregating[L]for typesGenTraversable[E],java.util.Collection[E],java.util.Map[K, V],String,Array[E]. Note that these are the same types as are supported withContaining, but withOption[E]missing. Here are some examples:The
containatLeastOneOfsyntax, for example, works for any typeLfor which anAggregating[L]exists. It ensures that at least one of (i.e., one or more of) the specified objects are contained in the containing object:Similar to
Containing[L], the implicit methods that provide theAggregating[L]instances require anEquality[E], whereEis an element type. For example, to obtain aAggregating[Vector[String]]you must supply anEquality[String], either implicitly or explicitly. Thecontainsyntax uses thisEquality[E]to determine containership. Thus if you want to change how containership is determined for an element typeE, place an implicitEquality[E]in scope or use the explicitly DSL. Although the implicit parameter required for thecontainsyntax is of typeAggregating[L], implicit conversions are provided in theAggregatingcompanion object fromEquality[E]to the various types of aggregations ofE. Here's an example:If you have a collection of elements that you'd like to use in an "at least one of" comparison, you can use "atLeastOneElementOf," like this:
The "
containatMostOneOf" syntax lets you specify a set of objects at most one of which must be contained in the containing object:If you have a collection of elements that you'd like to use in a "at most one of" comparison, you can use "atMostOneElementOf," like this:
The "
containallOf" syntax lets you specify a set of objects that must all be contained in the containing object:If you have a collection of elements that you'd like to use in a "all of" comparison, you can use "allElementsOf," like this:
The "
containonly" syntax lets you assert that the containing object contains only the specified objects, though it may contain more than one of each:The "
containtheSameElementsAs" and "containtheSameElementsInOrderAssyntax differ from the others in that the right hand side is aGenTraversable[_]rather than a varargs ofAny. (Note: in a future 2.0 milestone release, possibly 2.0.M6, these will likely be widened to accept any typeRfor which anAggregating[R]exists.)The "
containtheSameElementsAs" syntax lets you assert that two aggregations contain the same objects:The number of times any family of equal objects appears must also be the same in both the left and right aggregations. The specified objects may appear multiple times, but must appear in the order they appear in the right-hand list. For example, if the last 3 element is left out of the right-hand list in the previous example, the expression would fail because the left side has three 3's and the right hand side has only two:
List(1, 2, 2, 3, 3, 3) must contain theSameElementsAs Vector(3, 2, 3, 1, 2) org.scalatest.exceptions.TestFailedException: List(1, 2, 2, 3, 3, 3) did not contain the same elements as Vector(3, 2, 3, 1, 2) at ...Note that no
onlyElementsOfmatcher is provided, because it would have the same behavior astheSameElementsAs. (I.e., if you were looking foronlyElementsOf, please usetheSameElementsAsinstead.)Working with "sequences"
The rest of the
containsyntax, which will be described in this section, requires aSequencing[L]be provided, where againLis the left-hand type. (ASequencing[L]instance defines the "sequencing nature" of a typeL.) The reason, essentially, is thatcontainsyntax that implies an "order" of elements makes sense only for types that place elements in a sequence. For example, it doesn't make sense to assert that aMap[String, Int]orSet[Int]contains all of a set of integers in a particular order, as these types don't necessarily define an order for their elements. But this does make sense for a type such asSeq[Int]that does define an order for its elements.The
Sequencingcompanion object provides implicit instances ofSequencing[L]for typesGenSeq[E],java.util.List[E],String, andArray[E]. Here are some examples:Similar to
Containing[L], the implicit methods that provide theAggregating[L]instances require anEquality[E], whereEis an element type. For example, to obtain aAggregating[Vector[String]]you must supply anEquality[String], either implicitly or explicitly. Thecontainsyntax uses thisEquality[E]to determine containership. Thus if you want to change how containership is determined for an element typeE, place an implicitEquality[E]in scope or use the explicitly DSL. Although the implicit parameter required for thecontainsyntax is of typeAggregating[L], implicit conversions are provided in theAggregatingcompanion object fromEquality[E]to the various types of aggregations ofE. Here's an example:The "
containinOrderOnly" syntax lets you assert that the containing object contains only the specified objects, in order. The specified objects may appear multiple times, but must appear in the order they appear in the right-hand list. Here's an example:The "
containinOrder" syntax lets you assert that the containing object contains only the specified objects in order, likeinOrderOnly, but allows other objects to appear in the left-hand aggregation as well: contain more than one of each:If you have a collection of elements that you'd like to use in a "in order" comparison, you can use "inOrderElementsOf," like this:
Note that "order" in
inOrder,inOrderOnly, andtheSameElementsInOrderAs(described below) in theAggregation[L]instances built-in to ScalaTest is defined as "iteration order".Lastly, the "
containtheSameElementsInOrderAs" syntax lets you assert that two aggregations contain the same exact elements in the same (iteration) order:The previous assertion succeeds because the iteration order of a
TreeSetis the natural ordering of its elements, which in this case is 1, 2, 3. An iterator obtained from the left-handListwill produce the same elements in the same order.Note that no
inOrderOnlyElementsOfmatcher is provided, because it would have the same behavior astheSameElementsInOrderAs. (I.e., if you were looking forinOrderOnlyElementsOf, please usetheSameElementsInOrderAsinstead.)Working with "sortables"
You can also ask whether the elements of "sortable" objects (such as
Arrays, JavaLists, andGenSeqs) are in sorted order, like this:Working with iterators
Althought it seems desireable to provide similar matcher syntax for Scala and Java iterators to that provided for sequences like
Seqs,Array, andjava.util.List, the ephemeral nature of iterators makes this problematic. Some syntax (such asmustcontain) is relatively straightforward to support on iterators, but other syntax (such as, for example,Inspectorexpressions on nested iterators) is not. Rather than allowing inconsistencies between sequences and iterators in the API, we chose to not support any such syntax directly on iterators:Instead, you will need to convert your iterators to a sequence explicitly before using them in matcher expressions:
scala> it.toStream must contain (2)We recommend you convert (Scala or Java) iterators to
Streams, as shown in the previous example, so that you can continue to reap any potential benefits provided by the laziness of the underlying iterator.Inspector shorthands
You can use the
Inspectorssyntax with matchers as well as assertions. If you have a multi-dimensional collection, such as a list of lists, usingInspectorsis your best option:For assertions on one-dimensional collections, however, matchers provides "inspector shorthands." Instead of writing:
You can write:
all (xs) must be < 10The previous statement asserts that all elements of the
xslist must be less than 10. All of the inspectors have shorthands in matchers. Here is the full list:all- succeeds if the assertion holds true for every elementatLeast- succeeds if the assertion holds true for at least the specified number of elementsatMost- succeeds if the assertion holds true for at most the specified number of elementsbetween- succeeds if the assertion holds true for between the specified minimum and maximum number of elements, inclusiveevery- same asall, but lists all failing elements if it fails (whereasalljust reports the first failing element)exactly- succeeds if the assertion holds true for exactly the specified number of elementsHere are some examples:
scala> import org.scalatest.MustMatchers._ import org.scalatest.MustMatchers._ scala> val xs = List(1, 2, 3, 4, 5) xs: List[Int] = List(1, 2, 3, 4, 5) scala> all (xs) must be > 0 scala> atMost (2, xs) must be >= 4 scala> atLeast (3, xs) must be < 5 scala> between (2, 3, xs) must (be > 1 and be < 5) scala> exactly (2, xs) must be <= 2 scala> every (xs) must be < 10 scala> // And one that fails... scala> exactly (2, xs) mustEqual 2 org.scalatest.exceptions.TestFailedException: 'exactly(2)' inspection failed, because only 1 element satisfied the assertion block at index 1: at index 0, 1 did not equal 2, at index 2, 3 did not equal 2, at index 3, 4 did not equal 2, at index 4, 5 did not equal 2 in List(1, 2, 3, 4, 5) at ...Like
Inspectors, objects used with inspector shorthands can be any typeTfor which aCollecting[T, E]is availabe, which by default includesGenTraversable, JavaCollection, JavaMap,Arrays, andStrings. Here are some examples:scala> import org.scalatest._ import org.scalatest._ scala> import MustMatchers._ import MustMatchers._ scala> all (Array(1, 2, 3)) must be < 5 scala> import collection.JavaConverters._ import collection.JavaConverters._ scala> val js = List(1, 2, 3).asJava js: java.util.List[Int] = [1, 2, 3] scala> all (js) must be < 5 scala> val jmap = Map("a" -> 1, "b" -> 2).asJava jmap: java.util.Map[String,Int] = {a=1, b=2} scala> atLeast(1, jmap) mustBe Entry("b", 2) scala> atLeast(2, "hello, world!") mustBe 'o'Single-element collections
To assert both that a collection contains just one "lone" element as well as something else about that element, you can use the
loneElementsyntax provided by traitLoneElement. For example, if aSet[Int]must contain just one element, anIntless than or equal to 10, you could write:You can invoke
loneElementon any typeTfor which an implicitCollecting[E, T]is available, whereEis the element type returned by theloneElementinvocation. By default, you can useloneElementonGenTraversable, JavaCollection, JavaMap,Array, andString.Java collections and maps
You can use similar syntax on Java collections (
java.util.Collection) and maps (java.util.Map). For example, you can check whether a JavaCollectionorMapisempty, like this:Even though Java's
Listtype doesn't actually have alengthorgetLengthmethod, you can nevertheless check the length of a JavaList(java.util.List) like this:javaList must have length 9You can check the size of any Java
CollectionorMap, like this:In addition, you can check whether a Java
Collectioncontains a particular element, like this:javaCollection must contain ("five")One difference to note between the syntax supported on Java and Scala collections is that in Java,
Mapis not a subtype ofCollection, and does not actually define an element type. You can ask a JavaMapfor an "entry set" via theentrySetmethod, which will return theMap's key/value pairs wrapped in a set ofjava.util.Map.Entry, but aMapis not actually a collection ofEntry. To make JavaMaps easier to work with, however, ScalaTest matchers allows you to treat a JavaMapas a collection ofEntry, and defines a convenience implementation ofjava.util.Map.Entryinorg.scalatest.Entry. Here's how you use it:You can you alse just check whether a Java
Mapcontains a particular key, or value, like this:Strings andArrays as collectionsYou can also use all the syntax described above for Scala and Java collections on
Arrays andStrings. Here are some examples:scala> import org.scalatest._ import org.scalatest._ scala> import MustMatchers._ import MustMatchers._ scala> atLeast (2, Array(1, 2, 3)) must be > 1 scala> atMost (2, "halloo") mustBe 'o' scala> Array(1, 2, 3) mustBe sorted scala> "abcdefg" mustBe sorted scala> Array(1, 2, 3) must contain atMostOneOf (3, 4, 5) scala> "abc" must contain atMostOneOf ('c', 'd', 'e')beas an equality comparisonAll uses of
beother than those shown previously perform an equality comparison. They work the same asequalwhen it is used with default equality. This redundancy betweenbeandequalsexists in part because it enables syntax that sometimes sounds more natural. For example, instead of writing:result must equal (null)You can write:
result must be (null)(Hopefully you won't write that too much given
nullis error prone, andOptionis usually a better, well, option.) As mentioned previously, the other difference betweenequalandbeis thatequaldelegates the equality check to anEqualitytypeclass, whereasbealways uses default equality. Here are some other examples ofbeused for equality comparison:As with
equalused with default equality, usingbeon arrays results indeepbeing called on both arrays prior to callingequal. As a result, the following expression would not throw aTestFailedException:Because
beis used in several ways in ScalaTest matcher syntax, just as it is used in many ways in English, one potential point of confusion in the event of a failure is determining whetherbewas being used as an equality comparison or in some other way, such as a property assertion. To make it more obvious whenbeis being used for equality, the failure messages generated for those equality checks will include the wordequalin them. For example, if this expression fails with aTestFailedException:The detail message in that
TestFailedExceptionwill include the words"equal to"to signifybewas in this case being used for equality comparison:Being negative
If you wish to check the opposite of some condition, you can simply insert
notin the expression. Here are a few examples:Checking that a snippet of code does not compile
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
Matcherstrait includes the following syntax for that purpose:"val a: String = 1" mustNot compileIf you want to ensure that a snippet of code does not compile because of a type error (as opposed to a syntax error), use:
"val a: String = 1" mustNot typeCheckNote that the
mustNottypeChecksyntax will only succeed if the given snippet of code does not compile because of a type error. A syntax error will still result on a thrownTestFailedException.If you want to state that a snippet of code does compile, you can make that more obvious with:
"val a: Int = 1" must compileAlthough the previous three constructs are implemented with macros that determine at compile time whether the snippet of code represented by the string does or does not compile, errors are reported as test failures at runtime.
Logical expressions with
andandorYou can also combine matcher expressions with
andand/oror, however, you must place parentheses or curly braces around theandororexpression. For example, thisand-expression would not compile, because the parentheses are missing:Instead, you need to write:
Here are some more examples:
Two differences exist between expressions composed of these
andandoroperators and the expressions you can write on regularBooleans using its&&and||operators. First, expressions withandandordo not short-circuit. The following contrived expression, for example, would print"hello, world!":In other words, the entire
andororexpression is always evaluated, so you'll see any side effects of the right-hand side even if evaluating only the left-hand side is enough to determine the ultimate result of the larger expression. Failure messages produced by these expressions will "short-circuit," however, mentioning only the left-hand side if that's enough to determine the result of the entire expression. This "short-circuiting" behavior of failure messages is intended to make it easier and quicker for you to ascertain which part of the expression caused the failure. The failure message for the previous expression, for example, would be:Most likely this lack of short-circuiting would rarely be noticeable, because evaluating the right hand side will usually not involve a side effect. One situation where it might show up, however, is if you attempt to
andanullcheck on a variable with an expression that uses the variable, like this:If
mapisnull, the test will indeed fail, but with aNullArgumentException, not aTestFailedException. Here, theNullArgumentExceptionis the visible right-hand side effect. To get aTestFailedException, you would need to check each assertion separately:If
mapisnullin this case, thenullcheck in the first expression will fail with aTestFailedException, and the second expression will never be executed.The other difference with
Booleanoperators is that although&&has a higher precedence than||,andandorhave the same precedence. Thus although theBooleanexpression(a || b && c)will evaluate the&&expression before the||expression, like(a || (b && c)), the following expression:Will evaluate left to right, as:
If you really want the
andpart to be evaluated first, you'll need to put in parentheses, like this:Working with
OptionsYou can work with options using ScalaTest's equality,
empty,defined, andcontainsyntax. For example, if you wish to check whether an option isNone, you can write any of:If you wish to check an option is defined, and holds a specific value, you can write any of:
If you only wish to check that an option is defined, but don't care what it's value is, you can write:
If you mix in (or import the members of)
OptionValues, you can write one statement that indicates you believe an option must be defined and then say something else about its value. Here's an example:As mentioned previously, you can use also use ScalaTest's
contain,contain oneOf, andcontain noneOfsyntax with options:Checking arbitrary properties with
haveUsing
have, you can check properties of any type, where a property is an attribute of any object that can be retrieved either by a public field, method, or JavaBean-stylegetorismethod, like this:This expression will use reflection to ensure the
title,author, andpubYearproperties of objectbookare equal to the specified values. For example, it will ensure thatbookhas either a public Java field or method namedtitle, or a public method namedgetTitle, that when invoked (or accessed in the field case) results in a the string"Programming in Scala". If all specified properties exist and have their expected values, respectively, execution will continue. If one or more of the properties either does not exist, or exists but results in an unexpected value, aTestFailedExceptionwill be thrown that explains the problem. (For the details on how a field or method is selected during this process, see the documentation forHavePropertyMatcherGenerator.)When you use this syntax, you must place one or more property values in parentheses after
have, seperated by commas, where a property value is a symbol indicating the name of the property followed by the expected value in parentheses. The only exceptions to this rule is the syntax for checking size and length shown previously, which does not require parentheses. If you forget and put parentheses in, however, everything will still work as you'd expect. Thus instead of writing:You can alternatively, write:
If a property has a value different from the specified expected value, a
TestFailedErrorwill be thrown with a detailed message that explains the problem. For example, if you assert the following on abookwhose title isMoby Dick:You'll get a
TestFailedExceptionwith this detail message:The title property had value "Moby Dick", instead of its expected value "A Tale of Two Cities", on object Book("Moby Dick", "Melville", 1851)If you prefer to check properties in a type-safe manner, you can use a
HavePropertyMatcher. This would allow you to write expressions such as:These expressions would fail to compile if
mustis used on an inappropriate type, as determined by the type parameter of theHavePropertyMatcherbeing used. (For example,titlein this example might be of typeHavePropertyMatcher[org.publiclibrary.Book]. If used with an appropriate type, such an expression will compile and at run time the property method or field will be accessed directly; i.e., no reflection will be used. See the documentation forHavePropertyMatcherfor more information.Using
lengthandsizewithHavePropertyMatchersIf you want to use
lengthorsizesyntax with your own customHavePropertyMatchers, you can do so, but you must write(of [“the type”])afterwords. For example, you could write:Prior to ScalaTest 2.0, “
length(22)” yielded aHavePropertyMatcher[Any, Int]that used reflection to dynamically look for alengthfield orgetLengthmethod. In ScalaTest 2.0, “length(22)” yields aMatcherFactory1[Any, Length], so it is no longer aHavePropertyMatcher. The(of [<type>])syntax converts the theMatcherFactory1[Any, Length]to aHavePropertyMatcher[<type>, Int].Checking that an expression matches a pattern
ScalaTest's
Insidetrait allows you to make assertions after a pattern match. Here's an example:You can use
insideto just ensure a pattern is matched, without making any further assertions, but a better alternative for that kind of assertion ismatchPattern. ThematchPatternsyntax allows you to express that you expect a value to match a particular pattern, no more and no less:name must matchPattern { case Name("Sarah", _, _) => }Using custom matchers
If none of the built-in matcher syntax (or options shown so far for extending the syntax) satisfy a particular need you have, you can create custom
Matchers that allow you to place your own syntax directly aftermust. For example, classjava.io.Filehas a methodisHidden, which indicates whether a file of a certain path and name is hidden. Because theisHiddenmethod takes no parameters and returnsBoolean, you can call it usingbewith a symbol orBePropertyMatcher, yielding assertions like:If it doesn't make sense to have your custom syntax follow
be, you might want to create a customMatcherinstead, so your syntax can followmustdirectly. For example, you might want to be able to check whether ajava.io.File's name ends with a particular extension, like this:ScalaTest provides several mechanism to make it easy to create custom matchers, including ways to compose new matchers out of existing ones complete with new error messages. For more information about how to create custom
Matchers, please see the documentation for theMatchertrait.Checking for expected exceptions
Sometimes you need to test whether a method throws an expected exception under certain circumstances, such as when invalid arguments are passed to the method. With
Matchersmixed in, you can check for an expected exception like this:If
charAtthrows an instance ofStringIndexOutOfBoundsException, this expression will result in that exception. But ifcharAtcompletes normally, or throws a different exception, this expression will complete abruptly with aTestFailedException.If you need to further isnpect an expected exception, you can capture it using this syntax:
This expression returns the caught exception so that you can inspect it further if you wish, for example, to ensure that data contained inside the exception has the expected values. Here's an example:
thrown.getMessage must equal ("String index out of range: -1")If you prefer you can also capture and inspect an expected exception in one statement, like this:
You can also state that no exception must be thrown by some code, like this:
Those pesky parens
Perhaps the most tricky part of writing assertions using ScalaTest matchers is remembering when you need or don't need parentheses, but bearing in mind a few simple rules should help. It is also reassuring to know that if you ever leave off a set of parentheses when they are required, your code will not compile. Thus the compiler will help you remember when you need the parens. That said, the rules are:
1. Although you don't always need them, you may choose to always put parentheses around right-hand values, such as the
7innum must equal (7):2. Except for
length,sizeandmessage, you must always put parentheses around the list of one or more property values following ahave:3. You must always put parentheses around
andandorexpressions, as in:4. Although you don't always need them, you may choose to always put parentheses around custom
Matchers when they appear directly afternot:That's it. With a bit of practice it should become natural to you, and the compiler will always be there to tell you if you forget a set of needed parentheses.
Note: ScalaTest's matchers are in part inspired by the matchers of RSpec, Hamcrest, and specs2, and its “
mustNot compile” syntax by theillTypedmacro of shapeless.