MustMatchers

Trait that provides a domain specific language (DSL) for expressing assertions in tests using the word must.

Update: Although deprecated in 2.0, MustMatchers was resurrected in 2.1.0 in the org.scalatest package, so there's no need anymore to change must to should. In fact, the org.scalatest.MustMatchers type alias was accidentally left undeprecated in 2.0, so where you are mixing in trait org.scalatest.matchers.MustMatchers, you can in 2.0 get rid of the deprecation warning by mixing in org.scalatest.MustMatchers instead.

For example, if you mix Matchers into a suite class, you can write an equality assertion in that suite like this:

result must equal (3)

Here result is a variable, and can be of any type. If the object is an Int with the value 3, execution will continue (i.e., the expression will result in the unit value, ()). Otherwise, a TestFailedException will be thrown with a detail message that explains the problem, such as "7 did not equal 3". This TestFailedException will cause the test to fail.

Here is a table of contents for this documentation:

• Matchers migration in ScalaTest 2.0
• Checking equality with matchers
• Checking size and length
• Checking strings
• Greater and less than
• Checking Boolean properties with be
• Using custom BeMatchers
• Checking object identity
• Checking an object's class
• Checking numbers against a range
• Checking for emptiness
• Working with "containers"
• Working with "aggregations"
• Working with "sequences"
• Working with iterators
• Inspector shorthands
• Single-element collections
• Java collections and maps
• Be as an equality comparison
• Being negative
• Logical expressions with and and or
• Working with Options
• Checking arbitrary properties with have
• Using length and size with HavePropertyMatchers
• Using custom matchers
• Other ways to create matchers
• Checking for expected exceptions
• Those pesky parens

Matchers migration in ScalaTest 2.0

Deprecations

In ScalaTest 2.0, traits org.scalatest.matchers.MustMatchers and org.scalatest.matchers.MustMatchers are deprecated, replaced by trait org.scalatest.Matchers. MustMatchers and MustMatchers will continue to work during a lengthy deprecation cycle, but will eventually be removed in a future version of ScalaTest. You can migrate existing uses of MustMatchers by simply importing or mixing in org.scalatest.Matchers instead of org.scalatest.matchers.MustMatchers. You can migrate existing uses of org.scalatest.matchers.MustMatchers in the same manner, by importing or mixing in org.scalatest.Matchers instead of org.scalatest.matchers.MustMatchers, but with one extra step: replacing "should" with "must". org.scalatest.Matchers only supports the verb "must"; We apologize for imposing such a large search-and-replace job on users, but we want to make the verb "must" available to be used for a different purpose in ScalaTest after the deprecation cycle for MustMatchers is completed.

Two other deprecations in ScalaTest 2.0 matchers are be === <value> and evaluating ... must produce syntax. This will both continue to work as before, but will generate a deprecation warning and eventually be removed in a future version of ScalaTest. the be === syntax is being deprecated so that all uses of === in ScalaTest consistently provide the new features of tunable type checking, tolerance support, and customized equality. Please replace uses of this syntax with one of the other ways to check equality described in the next section. The eventually syntax is being deprecated because it is replaced by thrownBy clauses, as described below.

Potential breakages

Although ScalaTest's matchers have undergone a major refactor in 2.0, all previously documented syntax for matchers must continue to work exactly the same with one potential exception, which must in practice be extremely rare. The potential breakage is that if you included length or size along with custom have-property matchers that you wrote, you'll get a compiler error. To fix such an error, add after your length or size invocation an (of [<type>]) clause, as described below.

The only other source of potential breakage is the fragile base class problem. We have added fields and methods to Matchers in 2.0 that may conflict with fields and methods in your existing classes and cause a compiler error. Such issues can usually be easily fixed locally with simple renames or refactors, but if you prefer to subtract a token from Matchers, you can do so by mixing together your own Matchers trait from component traits, as described below. Note that you must not see any new implicit conflicts, because we managed to reduce the number of implicits brought into scope by 2.0 matchers compared to 1.x by about 75%.

Checking equality with matchers

ScalaTest matchers provides five different ways to check equality, each designed to address a different need. They are:

result must equal (3) // can customize equality
result must === (3)   // can customize equality and enforce type constraints
result must be (3)    // cannot customize equality, so fastest to compile
result mustEqual 3    // can customize equality, no parentheses required
result mustBe 3       // cannot customize equality, so fastest to compile, no parentheses required

The “left must equal (right)” syntax requires an org.scalautils.Equality[L] to be provided (either implicitly or explicitly), where L is the left-hand type on which must is invoked. In the "left must equal (right)" case, for example, L is the type of left. Thus if left is type Int, the "left must equal (right)" statement would require an Equality[Int].

By default, an implicit Equality[T] instance is available for any type T, in which equality is implemented by simply invoking == on the left value, passing in the right value, with special treatment for arrays. If either left or right is an array, deep will be invoked on it before comparing with ==. Thus, the following expression will yield false, because Array's equals method compares object identity:

Array(1, 2) == Array(1, 2) // yields false

The next expression will by default not result in a TestFailedException, because default Equality[Array[Int]] compares the two arrays structurally, taking into consideration the equality of the array's contents:

Array(1, 2) must 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, described below.

You can customize the meaning of equality for a type when using "must equal," "must ===," or mustEqual syntax by defining implicit Equality instances that will be used instead of default Equality. 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 compare Doubles with a tolerance. For an example, see the main documentation of trait Equality.

You can always supply implicit parameters explicitly, but in the case of implicit parameters of type Equality[T], ScalaUtils provides a simple "explictly" DSL. For example, here's how you could explicitly supply an Equality[String] instance that normalizes both left and right sides (which must be strings), by transforming them to lowercase:

scala> import org.scalatest.Matchers._
import org.scalatest.Matchers._
scala> import org.scalautils.Explicitly._
import org.scalautils.Explicitly._
scala> import org.scalautils.StringNormalizations._
import org.scalautils.StringNormalizations._
scala> "Hi" must equal ("hi") (after being lowerCased)

The after being lowerCased expression results in an Equality[String], which is then passed explicitly as the second curried parameter to equal. For more information on the explictly DSL, see the main documentation for trait Explicitly.

The "must be" and mustBe syntax do not take an Equality[T] and can therefore not be customized. They always use the default approach to equality described above. As a result, "must be" and mustBe will likely be the fastest-compiling matcher syntax for equality comparisons, since the compiler need not search for an implicit Equality[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.Matchers._
import org.scalatest.Matchers._
scala> import org.scalautils.TypeCheckedTripleEquals._
import org.scalautils.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.scalautils.Constraint[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 by TypeCheckedTripleEquals, however, the statement fails to compile. For more information and examples, see the main documentation for trait TypeCheckedTripleEquals.

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 3

Size is similar:

result must have size 10

The length syntax can be used with String, Array, any scala.collection.GenSeq, any java.util.List, and any type T for which an implicit Length[T] type class is available in scope. Similarly, the size syntax can be used with Array, any scala.collection.GenTraversable, any java.util.Collection, any java.util.Map, and any type T for which an implicit Size[T] type class is available in scope. You can enable the length or size syntax for your own arbitrary types, therefore, by defining Length or Size type classes for those types.

In addition, the length syntax can be used with any object that has a field or method named length or a method named getLength. Similarly, the size syntax can be used with any object that has a field or method named size or a method named getSize. The type of a length or size field, or return type of a method, must be either Int or Long. Any such method must take no parameters. (The Scala compiler will ensure at compile time that the object on which must is 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:

string must startWith ("Hello")
string must endWith ("world")
string must include ("seven")

You can check for whether a string starts with, ends with, or includes a regular expression, like this:

string must startWith regex "Hel*o"
string must endWith regex "wo.ld"
string must include regex "wo.ld"

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 regex token can be either a String or a scala.util.matching.Regex.

With the startWith, endWith, include, and fullyMatch tokens can also be used with an optional specification of required groups, like this:

"abbccxxx" must startWith regex ("a(b*)(c*)" withGroups ("bb", "cc"))
"xxxabbcc" must endWith regex ("a(b*)(c*)" withGroups ("bb", "cc"))
"xxxabbccxxx" must include regex ("a(b*)(c*)" withGroups ("bb", "cc"))
"abbcc" must fullyMatch regex ("a(b*)(c*)" withGroups ("bb", "cc"))

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 type T. The syntax is:

one must be < 7
one must be > 0
one must be <= 7
one must be >= 0

Checking Boolean properties with be

If an object has a method that takes no parameters and returns boolean, you can check it by placing a Symbol (after be) 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, 'traversableAgain results in a Symbol object at runtime, as does 'completed and 'file. Here's an example:

iter mustBe 'traversableAgain

Given this code, ScalaTest will use reflection to look on the object referenced from emptySet for a method that takes no parameters and results in Boolean, with either the name empty or isEmpty. If found, it will invoke that method. If the method returns true, execution will continue. But if it returns false, a TestFailedException will be thrown that will contain a detail message, such as:

non-empty iterator was not traversableAgain

This be syntax can be used with any reference (AnyRef) type. If the object does not have an appropriately named predicate method, you'll get a TestFailedException at 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 for BeWord.)

If you think it reads better, you can optionally put a or an after be. For example, java.io.File has two predicate methods, isFile and isDirectory. Thus with a File object named temp, you could write:

temp must be a 'file

Or, given java.awt.event.KeyEvent has a method isActionKey that takes no arguments and returns Boolean, you could assert that a KeyEvent is an action key with:

keyEvent must be an 'actionKey

If you prefer to check Boolean properties in a type-safe manner, you can use a BePropertyMatcher. This would allow you to write expressions such as:

xs mustBe traversableAgain
temp must be a file
keyEvent must be an actionKey

These expressions would fail to compile if must is used on an inappropriate type, as determined by the type parameter of the BePropertyMatcher being used. (For example, file in this example would likely be of type BePropertyMatcher[java.io.File]. If used with an appropriate type, such an expression will compile and at run time the Boolean property method or field will be accessed directly; i.e., no reflection will be used. See the documentation for BePropertyMatcher for more information.

Using custom BeMatchers

If 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 a BeMatcher. You could use this, for example, to create BeMatcher[Int] called odd, which would match any odd Int, and even, which would match any even Int. Given this pair of BeMatchers, you could check whether an Int was odd or even with expressions like:

num mustBe odd
num must not be even

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:

ref1 must be theSameInstanceAs ref2

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 “be a” or “be an”:

result1 mustBe a [Tiger]
result1 must not be an [Orangutan]

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:

result mustBe a [List[_]] // recommended
result mustBe a [List[Fruit]] // discouraged

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:

sevenDotOh must equal (6.9 +- 0.2)
sevenDotOh must === (6.9 +- 0.2)
sevenDotOh must be (6.9 +- 0.2)
sevenDotOh mustEqual 6.9 +- 0.2
sevenDotOh mustBe 6.9 +- 0.2

Any of these expressions will cause a TestFailedException to be thrown if the floating point value, sevenDotOh is outside the range 6.7 to 7.1. You can use +- with any type T for which an implicit Numeric[T] exists, such as integral types:

seven must equal (6 +- 2)
seven must === (6 +- 2)
seven must be (6 +- 2)
seven mustEqual 6 +- 2
seven mustBe 6 +- 2

Checking for emptiness

You can check whether an object is "empty", like this:

traversable mustBe empty
javaMap must not be empty

The empty token can be used with any type L for which an implicit Emptiness[L] exists. The Emptiness companion object provides implicits for GenTraversable[E], java.util.Collection[E], java.util.Map[K, V], String, Array[E], and Option[E]. In addition, the Emptiness companion object provides structural implicits for types that declare an isEmpty method that returns a Boolean. Here are some examples:

scala> import org.scalatest.Matchers._
import org.scalatest.Matchers._
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 empty

Working with "containers"

You can check whether a collection contains a particular element like this:

traversable must contain ("five")

The contain syntax shown above can be used with any type C that has a "containing" nature, evidenced by an implicit org.scalatest.enablers.Containing[L], where L is left-hand type on which must is invoked. In the Containing companion object, implicits are provided for types GenTraversable[E], java.util.Collection[E], java.util.Map[K, V], String, Array[E], and Option[E]. Here are some examples:

scala> import org.scalatest.Matchers._
import org.scalatest.Matchers._
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 an Equality[E], where E is an element type. For example, to obtain a Containing[Array[Int]] you must supply an Equality[Int], either implicitly or explicitly. The contain syntax uses this Equality[E] to determine containership. Thus if you want to change how containership is determined for an element type E, place an implicit Equality[E] in scope or use the explicitly DSL. Although the implicit parameter required for the contain syntax is of type Containing[L], implicit conversions are provided in the Containing companion object from Equality[E] to the various types of containers of E. Here's an example:

scala> import org.scalatest.Matchers._
import org.scalatest.Matchers._
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.scalautils.Explicitly._
import org.scalautils.Explicitly._
scala> import org.scalautils.StringNormalizations._
import org.scalautils.StringNormalizations._
scala> (List("Hi", "Di", "Ho") must contain ("ho")) (after being lowerCased)

Note that when you use the explicitly DSL with contain you need to wrap the entire contain expression 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 contain to make other determinations. For example, the contain oneOf syntax ensures that one and only one of the specified elements are contained in the containing object:

List(1, 2, 3, 4, 5) must contain oneOf (5, 7, 9)
Some(7) must contain oneOf (5, 7, 9)
"howdy" must contain oneOf ('a', 'b', 'c', 'd')

Note that if multiple specified elements appear in the containing object, oneOf will fail:

scala> List(1, 2, 3) must contain oneOf (2, 3, 4)
org.scalatest.exceptions.TestFailedException: List(1, 2, 3) did not contain 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 of oneOf. Keep in mind, oneOf means "exactly one of."

Note also that with any contain syntax, you can place custom implicit Equality[E] instances in scope to customize how containership is determined, or use the explicitly DSL. Here's an example:

(Array("Doe", "Ray", "Me") must contain oneOf ("X", "RAY", "BEAM")) (after being lowerCased)

The contain noneOf syntax does the opposite of oneOf: it ensures none of the specified elements are contained in the containing object:

List(1, 2, 3, 4, 5) must contain noneOf (7, 8, 9)
Some(0) must contain noneOf (7, 8, 9)
"12345" must contain noneOf ('7', '8', '9')

Working with "aggregations"

As mentioned, the "contain," "contain oneOf," and "contain noneOf" syntax requires a Containing[L] be provided, where L is the left-hand type. Other contain syntax, which will be described in this section, requires an Aggregating[L] be provided, where again L is the left-hand type. (An Aggregating[L] instance defines the "aggregating nature" of a type L.) The reason, essentially, is that contain syntax that makes sense for Option is enabled by Containing[L], whereas syntax that does not make sense for Option is enabled by Aggregating[L]. For example, it doesn't make sense to assert that an Option[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 as List[Int] that can aggregate zero to many integers.

The Aggregating companion object provides implicit instances of Aggregating[L] for types GenTraversable[E], java.util.Collection[E], java.util.Map[K, V], String, Array[E]. Note that these are the same types as are supported with Containing, but with Option[E] missing. Here are some examples:

The contain atLeastOneOf syntax, for example, works for any type L for which an Aggregating[L] exists. It ensures that at least one of (i.e., one or more of) the specified objects are contained in the containing object:

List(1, 2, 3) must contain atLeastOneOf (2, 3, 4)
Array(1, 2, 3) must contain atLeastOneOf (3, 4, 5)
"abc" must contain atLeastOneOf ('c', 'a', 't')

Similar to Containing[L], the implicit methods that provide the Aggregating[L] instances require an Equality[E], where E is an element type. For example, to obtain a Aggregating[Vector[String]] you must supply an Equality[String], either implicitly or explicitly. The contain syntax uses this Equality[E] to determine containership. Thus if you want to change how containership is determined for an element type E, place an implicit Equality[E] in scope or use the explicitly DSL. Although the implicit parameter required for the contain syntax is of type Aggregating[L], implicit conversions are provided in the Aggregating companion object from Equality[E] to the various types of aggregations of E. Here's an example:

(Vector(" A", "B ") must contain atLeastOneOf ("a ", "b", "c")) (after being lowerCased and trimmed)

The "contain atMostOneOf" syntax lets you specify a set of objects at most one of which must be contained in the containing object:

List(1, 2, 3, 4, 5) must contain atMostOneOf (5, 6, 7)

The "contain allOf" syntax lets you specify a set of objects that must all be contained in the containing object:

List(1, 2, 3, 4, 5) must contain allOf (2, 3, 5)

The "contain only" syntax lets you assert that the containing object contains only the specified objects, though it may contain more than one of each:

List(1, 2, 3, 2, 1) must contain only (1, 2, 3)

The "contain theSameElementsAs" and "contain theSameElementsInOrderAs syntax differ from the others in that the right hand side is a GenTraversable[_] rather than a varargs of Any. (Note: in a future 2.0 milestone release, possibly 2.0.M6, these will likely be widened to accept any type R for which an Aggregating[R] exists.)

The "contain theSameElementsAs" syntax lets you assert that two aggregations contain the same objects:

List(1, 2, 2, 3, 3, 3) must contain theSameElementsAs Vector(3, 2, 3, 1, 2, 3)

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 ...

Working with "sequences"

The rest of the contain syntax, which will be described in this section, requires a Sequencing[L] be provided, where again L is the left-hand type. (A Sequencing[L] instance defines the "sequencing nature" of a type L.) The reason, essentially, is that contain syntax 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 a Map[String, Int] or Set[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 as Seq[Int] that does define an order for its elements.

The Sequencing companion object provides implicit instances of Sequencing[L] for types GenSeq[E], java.util.List[E], String, and Array[E]. Here are some examples:

Similar to Containing[L], the implicit methods that provide the Aggregating[L] instances require an Equality[E], where E is an element type. For example, to obtain a Aggregating[Vector[String]] you must supply an Equality[String], either implicitly or explicitly. The contain syntax uses this Equality[E] to determine containership. Thus if you want to change how containership is determined for an element type E, place an implicit Equality[E] in scope or use the explicitly DSL. Although the implicit parameter required for the contain syntax is of type Aggregating[L], implicit conversions are provided in the Aggregating companion object from Equality[E] to the various types of aggregations of E. Here's an example:

The "contain inOrderOnly" 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:

List(1, 2, 2, 3, 3, 3) must contain inOrderOnly (1, 2, 3)

The "contain inOrder" syntax lets you assert that the containing object contains only the specified objects in order, like inOrderOnly, but allows other objects to appear in the left-hand aggregation as well: contain more than one of each:

List(0, 1, 2, 2, 99, 3, 3, 3, 5) must contain inOrder (1, 2, 3)

Note that "order" in inOrder, inOrderOnly, and theSameElementsInOrderAs (described below) in the Aggregation[L] instances built-in to ScalaTest is defined as "iteration order".

Lastly, the "contain theSameElementsInOrderAs" syntax lets you assert that two aggregations contain the same exact elements in the same (iteration) order:

List(1, 2, 3) must contain theSameElementsInOrderAs collection.mutable.TreeSet(3, 2, 1)

The previous assertion succeeds because the iteration order of aTreeSet is the natural ordering of its elements, which in this case is 1, 2, 3. An iterator obtained from the left-hand List will produce the same elements in the same order.

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, and java.util.List, the ephemeral nature of iterators makes this problematic. Some syntax (such as must contain) is relatively straightforward to support on iterators, but other syntax (such as, for example, Inspector expressions 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:

scala> val it = List(1, 2, 3).iterator
it: Iterator[Int] = non-empty iterator

scala> it must contain (2)
<console>:15: error: could not find implicit value for parameter typeClass1: org.scalatest.enablers.Containing[Iterator[Int]]
           it must contain (2)
              ^

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 Inspectors syntax with matchers as well as assertions. If you have a multi-dimensional collection, such as a list of lists, using Inspectors is your best option:

val yss =
  List(
    List(1, 2, 3),
    List(1, 2, 3),
    List(1, 2, 3)
  )

forAll (yss) { ys =>
  forAll (ys) { y => y must be > 0 }
}

For assertions on one-dimensional collections, however, matchers provides "inspector shorthands." Instead of writing:

val xs = List(1, 2, 3)
forAll (xs) { x => x must be < 10 }

You can write:

all (xs) must be < 10

The previous statement asserts that all elements of the xs list 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 element
• atLeast - succeeds if the assertion holds true for at least the specified number of elements
• atMost - succeeds if the assertion holds true for at most the specified number of elements
• between - succeeds if the assertion holds true for between the specified minimum and maximum number of elements, inclusive
• every - same as all, but lists all failing elements if it fails (whereas all just reports the first failing element)
• exactly - succeeds if the assertion holds true for exactly the specified number of elements

Here are some examples:

scala> import org.scalatest.Matchers._
import org.scalatest.Matchers._
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 ...

Note: in the current 2.0.M6-SNAP release, the type of object used with inspector shorthands must be GenTraversable, but this will likely be widened to include Java collections, arrays, iterators, etc., for 2.0.M6.

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 loneElement syntax. For example, if a Set[Int] must contain just one element, an Int less than or equal to 10, you could write:

set.loneElement must be <= 10

You can invoke loneElement on any type T for which an implicit Collecting[E, T] is available, where E is the type returned by the loneElement invocation.

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 Java Collection or Map is empty, like this:

javaCollection must be ('empty)
javaMap must be ('empty)

Even though Java's List type doesn't actually have a length or getLength method, you can nevertheless check the length of a Java List (java.util.List) like this:

javaList must have length 9

You can check the size of any Java Collection or Map, like this:

javaMap must have size 20
javaSet must have size 90

In addition, you can check whether a Java Collection contains 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, Map is not a subtype of Collection, and does not actually define an element type. You can ask a Java Map for an "entry set" via the entrySet method, which will return the Map's key/value pairs wrapped in a set of java.util.Map.Entry, but a Map is not actually a collection of Entry. To make Java Maps easier to work with, however, ScalaTest matchers allows you to treat a Java Map as a collection of Entry, and defines a convenience implementation of java.util.Map.Entry in org.scalatest.Entry. Here's how you use it:

javaMap must contain (Entry(2, 3))
javaMap must contain oneOf (Entry(2, 3), Entry(3, 4))

You can you alse just check whether a Java Map contains a particular key, or value, like this:

javaMap must contain key 1
javaMap must contain value "Howdy"

be as an equality comparison

All uses of be other than those shown previously perform an equality comparison. They work the same as equal when it is used with default equality. This redundancy between be and equals exists 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 null is error prone, and Option is usually a better, well, option.) Here are some other examples of be used for equality comparison:

sum must be (7.0)
boring must be (false)
fun must be (true)
list must be (Nil)
option must be (None)
option must be (Some(1))

As with equal used with default equality, using be on arrays results in deep being called on both arrays prior to calling equal. As a result, the following expression would not throw a TestFailedException:

Array(1, 2) must be (Array(1, 2)) // succeeds (i.e., does not throw TestFailedException)

Because be is 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 whether be was being used as an equality comparison or in some other way, such as a property assertion. To make it more obvious when be is being used for equality, the failure messages generated for those equality checks will include the word equal in them. For example, if this expression fails with a TestFailedException:

option must be (Some(1))

The detail message in that TestFailedException will include the words "equal to" to signify be was in this case being used for equality comparison:

Some(2) was not equal to Some(1)

Being negative

If you wish to check the opposite of some condition, you can simply insert not in the expression. Here are a few examples:

result must not be (null)
sum must not be <= (10)
mylist must not equal (yourList)
string must not startWith ("Hello")

Logical expressions with and and or

You can also combine matcher expressions with and and/or or, however, you must place parentheses or curly braces around the and or or expression. For example, this and-expression would not compile, because the parentheses are missing:

map must contain key ("two") and not contain value (7) // ERROR, parentheses missing!

Instead, you need to write:

map must (contain key ("two") and not contain value (7))

Here are some more examples:

number must (be > (0) and be <= (10))
option must (equal (Some(List(1, 2, 3))) or be (None))
string must (
  equal ("fee") or
  equal ("fie") or
  equal ("foe") or
  equal ("fum")
)

Two differences exist between expressions composed of these and and or operators and the expressions you can write on regular Booleans using its && and || operators. First, expressions with and and or do not short-circuit. The following contrived expression, for example, would print "hello, world!":

"yellow" must (equal ("blue") and equal { println("hello, world!"); "green" })

In other words, the entire and or or expression 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:

"yellow" did not equal "blue"

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 and a null check on a variable with an expression that uses the variable, like this:

map must (not be (null) and contain key ("ouch"))

If map is null, the test will indeed fail, but with a NullPointerException, not a TestFailedException. Here, the NullPointerException is the visible right-hand side effect. To get a TestFailedException, you would need to check each assertion separately:

map must not be (null)
map must contain key ("ouch")

If map is null in this case, the null check in the first expression will fail with a TestFailedException, and the second expression will never be executed.

The other difference with Boolean operators is that although && has a higher precedence than ||, and and or have the same precedence. Thus although the Boolean expression (a || b && c) will evaluate the && expression before the || expression, like (a || (b && c)), the following expression:

traversable must (contain (7) or contain (8) and have size (9))

Will evaluate left to right, as:

traversable must ((contain (7) or contain (8)) and have size (9))

If you really want the and part to be evaluated first, you'll need to put in parentheses, like this:

traversable must (contain (7) or (contain (8) and have size (9)))

Working with Options

ScalaTest matchers has no special support for Options, but you can work with them quite easily using syntax shown previously. For example, if you wish to check whether an option is None, you can write any of:

option must equal (None)
option must be (None)
option must not be ('defined)
option must be ('empty)

If you wish to check an option is defined, and holds a specific value, you can write either of:

option must equal (Some("hi"))
option must be (Some("hi"))

If you only wish to check that an option is defined, but don't care what it's value is, you can write:

option must be ('defined)

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:

import org.scalatest.OptionValues._
option.value must be < (7)

Checking arbitrary properties with have

Using 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-style get or is method, like this:

book must have (
  'title ("Programming in Scala"),
  'author (List("Odersky", "Spoon", "Venners")),
  'pubYear (2008)
)

This expression will use reflection to ensure the title, author, and pubYear properties of object book are equal to the specified values. For example, it will ensure that book has either a public Java field or method named title, or a public method named getTitle, 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, a TestFailedException will be thrown that explains the problem. (For the details on how a field or method is selected during this process, see the documentation for HavePropertyMatcherGenerator.)

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:

array must have length (3)
set must have size (90)

You can alternatively, write:

array must have (length (3))
set must have (size (90))

If a property has a value different from the specified expected value, a TestFailedError will be thrown with a detailed message that explains the problem. For example, if you assert the following on a book whose title is Moby Dick:

book must have ('title ("A Tale of Two Cities"))

You'll get a TestFailedException with 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:

book must have (
  title ("Programming in Scala"),
  author (List("Odersky", "Spoon", "Venners")),
  pubYear (2008)
)

These expressions would fail to compile if must is used on an inappropriate type, as determined by the type parameter of the HavePropertyMatcher being used. (For example, title in this example might be of type HavePropertyMatcher[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 for HavePropertyMatcher for more information.

Using length and size with HavePropertyMatchers

If you want to use length or size syntax with your own custom HavePropertyMatchers, you can do so, but you must write (of [“the type”]) afterwords. For example, you could write:

book must have (
  title ("A Tale of Two Cities"),
  length (220) (of [Book]),
  author ("Dickens")
)

Prior to ScalaTest 2.0, “length (22)” yielded a HavePropertyMatcher[Any, Int] that used reflection to dynamically look for a length field or getLength method. In ScalaTest 2.0, “length (22)” yields a MatcherFactory1[Any, Length], so it is no longer a HavePropertyMatcher. The (of [<type>]) syntax converts the the MatcherFactory1[Any, Length] to a HavePropertyMatcher[<type>, Int].

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 after must. For example, class java.io.File has a method isHidden, which indicates whether a file of a certain path and name is hidden. Because the isHidden method takes no parameters and returns Boolean, you can call it using be with a symbol or BePropertyMatcher, yielding assertions like:

file must be ('hidden)  // using a symbol
file must be (hidden)   // using a BePropertyMatcher

If it doesn't make sense to have your custom syntax follow be, you might want to create a custom Matcher instead, so your syntax can follow must directly. For example, you might want to be able to check whether a java.io.File's name ends with a particular extension, like this:

// using a plain-old Matcher
file must endWithExtension ("txt")

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 the Matcher trait.

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 Matchers mixed in, you can check for an expected exception like this:

an [IndexOutOfBoundsException] must be thrownBy s.charAt(-1)

If charAt throws an instance of StringIndexOutOfBoundsException, this expression will result in that exception. But if charAt completes normally, or throws a different exception, this expression will complete abruptly with a TestFailedException.

If you need to further isnpect an expected exception, you can capture it using this syntax:

val thrown = the [IndexOutOfBoundsException] thrownBy s.charAt(-1)

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:

the [ArithmeticException] thrownBy 1 / 0 must have message "/ by zero"
the [IndexOutOfBoundsException] thrownBy {
  s.charAt(-1)
} must have message "String index out of range: -1"

You can also state that no exception must be thrown by some code, like this:

noException must be thrownBy 0 / 1

Note: the following syntax from ScalaTest 1.x has been deprecated:

evaluating { s.charAt(-1) } must produce [IndexOutOfBoundsException]

Such uses will continue to work during the deprecation cycle, but support for this syntax will eventually be removed in a future version of ScalaTest. Please change all uses to a corresponding use of the syntax described previously in this section.

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, it is recommended style to always put parentheses around right-hand values, such as the 7 in num must equal (7):

result must equal (4)
array must have length (3)
book must have (
  'title ("Programming in Scala"),
  'author (List("Odersky", "Spoon", "Venners")),
  'pubYear (2008)
)
option must be ('defined)
catMap must (contain key (9) and contain value ("lives"))
keyEvent must be an ('actionKey)
javaSet must have size (90)

2. Except for length and size, you must always put parentheses around the list of one or more property values following a have:

file must (exist and have ('name ("temp.txt")))
book must have (
  title ("Programming in Scala"),
  author (List("Odersky", "Spoon", "Venners")),
  pubYear (2008)
)
javaList must have length (9) // parens optional for length and size

3. You must always put parentheses around and and or expressions, as in:

catMap must (contain key (9) and contain value ("lives"))
number must (equal (2) or equal (4) or equal (8))

4. Although you don't always need them, it is recommended style to always put parentheses around custom Matchers when they appear directly after not:

file must exist
file must not (exist)
file must (exist and have ('name ("temp.txt")))
file must (not (exist) and have ('name ("temp.txt"))
file must (have ('name ("temp.txt") or exist)
file must (have ('name ("temp.txt") or not (exist))

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.