Matcher

Trait extended by objects that can match a value of the specified type. The value to match is passed to the matcher's apply method. The result is a MatchResult. A matcher is, therefore, a function from the specified type, T, to a MatchResult.

Creating custom matchers

Note: We are planning on adding some new matchers to ScalaTest in a future release, and would like your feedback. Please let us know if you have felt the need for a matcher ScalaTest doesn't yet provide, whether or not you wrote a custom matcher for it. Please email your feedback to bill AT artima.com.

If none of the built-in matcher syntax satisfies a particular need you have, you can create custom Matchers that allow you to place your own syntax directly after should or must. For example, class java.io.File has a method exists, which indicates whether a file of a certain path and name exists. Because the exists method takes no parameters and returns Boolean, you can call it using be with a symbol or BePropertyMatcher, yielding assertions like:

file should be ('exists)  // using a symbol
file should be (inExistance)   // using a BePropertyMatcher

Although these expressions will achieve your goal of throwing a TestFailedException if the file does not exist, they don't produce the most readable code because the English is either incorrect or awkward. In this case, you might want to create a custom Matcher[java.io.File] named exist, which you could then use to write expressions like:

// using a plain-old Matcher
file should exist
file should not (exist)
file should (exist and have ('name ("temp.txt")))

One good way to organize custom matchers is to place them inside one or more traits that you can then mix into the suites or specs that need them. Here's an example:

trait CustomMatchers {

  class FileExistsMatcher extends Matcher[java.io.File] {

    def apply(left: java.io.File) = {

      val fileOrDir = if (left.isFile) "file" else "directory"

      val failureMessageSuffix =
        fileOrDir + " named " + left.getName + " did not exist"

      val negatedFailureMessageSuffix =
        fileOrDir + " named " + left.getName + " existed"

      MatchResult(
        left.exists,
        "The " + failureMessageSuffix,
        "The " + negatedFailureMessageSuffix,
        "the " + failureMessageSuffix,
        "the " + negatedFailureMessageSuffix
      )
    }
  }

  val exist = new FileExistsMatcher
}

// Make them easy to import with:
// import CustomMatchers._
object CustomMatchers extends CustomMatchers

Note: the CustomMatchers companion object exists to make it easy to bring the matchers defined in this trait into scope via importing, instead of mixing in the trait. The ability to import them is useful, for example, when you want to use the matchers defined in a trait in the Scala interpreter console.

This trait contains one matcher class, FileExistsMatcher, and a val named exist that refers to an instance of FileExistsMatcher. Because the class extends Matcher[java.io.File], the compiler will only allow it be used to match against instances of java.io.File. A matcher must declare an apply method that takes the type decared in Matcher's type parameter, in this case java.io.File. The apply method will return a MatchResult whose matches field will indicate whether the match succeeded. The failureMessage field will provide a programmer-friendly error message indicating, in the event of a match failure, what caused the match to fail.

The FileExistsMatcher matcher in this example determines success by calling exists on the passed java.io.File. It does this in the first argument passed to the MatchResult factory method:

left.exists,

In other words, if the file exists, this matcher matches. The next argument to MatchResult's factory method produces the failure message string:

"The " + failureMessageSuffix,

If the passed java.io.File is a file (not a directory) and has the name temp.txt, for example, the failure message would be:

The file named temp.txt did not exist

For more information on the fields in a MatchResult, including the subsequent three fields that follow the failure message, please see the documentation for MatchResult.

Given the CustomMatchers trait as defined above, you can use the exist syntax in any suite or spec in which you mix in the trait:

class ExampleSpec extends Spec with ShouldMatchers with CustomMatchers {

  describe("A temp file") {

    it("should be created and deleted") {

      val tempFile = java.io.File.createTempFile("delete", "me")

      try {
        // At this point the temp file should exist
        tempFile should exist
      }
      finally {
        tempFile.delete()
      }

      // At this point it should not exist
      tempFile should not (exist)
    }
  }
}

Note that when you use custom Matchers, you will need to put parentheses around the custom matcher when if follows not, as shown in the last assertion above: tempFile should not (exist).

Other ways to create matchers

There are other ways to create new matchers besides defining one as shown above. For example, you would normally check to ensure an option is defined like this:

Some("hi") should be ('defined)

If you wanted to get rid of the tick mark, you could simply define defined like this:

val defined = 'defined

Now you can check that an option is defined without the tick mark:

Some("hi") should be (defined)

Perhaps after using that for a while, you realize you're tired of typing the parentheses. You could get rid of them with another one-liner:

val beDefined = be (defined)

Now you can check that an option is defined without the tick mark or the parentheses:

Some("hi") should beDefined

You can also use ScalaTest matchers' logical operators to combine existing matchers into new ones, like this:

val beWithinTolerance = be >= 0 and be <= 10

Now you could check that a number is within the tolerance (in this case, between 0 and 10, inclusive), like this:

num should beWithinTolerance

When defining a full blown matcher, one shorthand is to use one of the factory methods in Matcher's companion object. For example, instead of writing this:

val beOdd =
  new Matcher[Int] {
    def apply(left: Int) =
      MatchResult(
        left % 2 == 1,
        left + " was not odd",
        left + " was odd"
      )
  }

You could alternately write this:

val beOdd =
  Matcher { (left: Int) =>
    MatchResult(
      left % 2 == 1,
      left + " was not odd",
      left + " was odd"
    )
  }

Either way you define the beOdd matcher, you could use it like this:

3 should beOdd
4 should not (beOdd)

You can also compose matchers. If for some odd reason, you wanted a Matcher[String] that checked whether a string, when converted to an Int, was odd, you could make one by composing beOdd with a function that converts a string to an Int, like this:

val beOddAsInt = beOdd compose { (s: String) => s.toInt }

Now you have a Matcher[String] whose apply method first invokes the converter function to convert the passed string to an Int, then passes the resulting Int to beOdd. Thus, you could use beOddAsInt like this:

"3" should beOddAsInt
"4" should not (beOddAsInt)

Matcher's variance

Matcher is contravariant in its type parameter, T, to make its use more flexible. As an example, consider the hierarchy:

class Fruit
class Orange extends Fruit
class ValenciaOrange extends Orange

Given an orange:

val orange = Orange

The expression "orange should" will, via an implicit conversion in ShouldMatchers, result in an object that has a should method that takes a Matcher[Orange]. If the static type of the matcher being passed to should is Matcher[Valencia] it shouldn't (and won't) compile. The reason it shouldn't compile is that the left value is an Orange, but not necessarily a Valencia, and a Matcher[Valencia] only knows how to match against a Valencia. The reason it won't compile is given that Matcher is contravariant in its type parameter, T, a Matcher[Valencia] is not a subtype of Matcher[Orange].

By contrast, if the static type of the matcher being passed to should is Matcher[Fruit], it should (and will) compile. The reason it should compile is that given the left value is an Orange, it is also a Fruit, and a Matcher[Fruit] knows how to match against Fruits. The reason it will compile is that given that Matcher is contravariant in its type parameter, T, a Matcher[Fruit] is indeed a subtype of Matcher[Orange].