Section 14.6

Chapter 14 · Assertions and Unit Testing

305

Like ScalaTest, specs provides a matchers DSL. You can see some examples of specs matchers in action in Listing 14.8 in the lines that contain “must be_==” and “must throwA”. You can use specs standalone, but it is also integrated with ScalaTest and JUnit, so you can run specs tests with those tools as well.3

14.6 Property-based testing

Another useful testing tool for Scala is ScalaCheck, an open source framework written by Rickard Nilsson. ScalaCheck enables you to specify properties that the code under test must obey. For each property, ScalaCheck will generate test data and run tests that check whether the property holds. Listing 14.9 show an example of using ScalaCheck from a ScalaTest WordSpec that mixes in trait Checkers:

import org.scalatest.WordSpec import org.scalatest.prop.Checkers import org.scalacheck.Prop._ import Element.elem

class ElementSpec extends WordSpec with Checkers {

"elem result" must { "have passed width" in {

check((w: Int) => w > 0 ==> (elem('x', w, 3).width == w))

}

"have passed height" in {

check((h: Int) => h > 0 ==> (elem('x', 2, h).height == h))

}

}

}

Listing 14.9 · Writing property-based tests with ScalaCheck.

WordSpec is a ScalaTest trait that provides syntax similar to a specs Specification. The Checkers trait provides several check methods that allow you to mix ScalaCheck property-based tests with traditional assertion-

3You can download specs from http://code.google.com/p/specs/.

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

Section 14.7

Chapter 14 · Assertions and Unit Testing

306

or matcher-based tests. In this example, we check two properties that the elem factory should obey. ScalaCheck properties are expressed as function values that take as parameters the required test data, which will be generated by ScalaCheck. In the first property shown in Listing 14.9, the test data is an integer named w that represents a width. Inside the body of the function, you see this code:

w > 0 ==> (elem('x', w, 3).width == w)

The ==> symbol is a ScalaCheck implication operator. It implies that whenever the left hand expression is true, the expression on the right must hold true. Thus in this case, the expression on the right of ==> must hold true whenever w is greater than 0. The right-hand expression in this case will yield true if the width passed to the elem factory is the same as the width of the Element returned by the factory.

With this small amount of code, ScalaCheck will generate possibly hundreds of values for w and test each one, looking for a value for which the property doesn’t hold. If the property holds true for every value ScalaCheck tries, the test will pass. Otherwise, the test will complete abruptly with an AssertionError that contains information including the value that caused the failure.

14.7 Organizing and running tests

Each framework mentioned in this chapter provides some mechanism for organizing and running tests. In this section, we’ll give a quick overview of ScalaTest’s approach. To get the full story on any of these frameworks, however, you’ll need to consult their documentation.

In ScalaTest, you organize large test suites by nesting Suites inside Suites. When a Suite is executed, it will execute its nested Suites as well as its tests. The nested Suites will in turn execute their nested Suites, and so on. A large test suite, therefore, is represented as a tree of Suite objects. When you execute the root Suite in the tree, all Suites in the tree will be executed.

You can nest suites manually or automatically. To nest manually, you either override the nestedSuites method on your Suites, or pass the Suites you want to nest to the constructor of class SuperSuite, which ScalaTest provides for this purpose. To nest automatically, you provide package names

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

Section 14.7

Chapter 14 · Assertions and Unit Testing

307

Figure 14.1 · ScalaTest’s graphical reporter.

to ScalaTest’s Runner, which will discover Suites automatically, nest them under a root Suite, and execute the root Suite.

You can invoke ScalaTest’s Runner application from the command line or an ant task. You must specify which suites you want to run, either by naming the suites explicitly or indicating name prefixes with which you want Runner to perform automatic discovery. You can optionally specify a runpath, a list of directories and JAR files from which to load class files for the tests and the code they exercise.4 You can also specify one or more reporters, which will determine how test results will be presented.

For example, the ScalaTest distribution includes the suites that test ScalaTest itself. You can run one of these suites, SuiteSuite,5 with the following command:

$ scala -cp scalatest-1.2.jar org.scalatest.tools.Runner

-p "scalatest-1.2-tests.jar" -s org.scalatest.SuiteSuite

With -cp you place ScalaTest’s JAR file on the class path. The next token, org.scalatest.tools.Runner, is the fully qualified name of the Runner

4Tests can be anywhere on the runpath or classpath, but typically you would keep your tests separate from your production code, in a separate directory hierarchy that mirrors your source tree’s directory hierarchy.

5SuiteSuite is so-named because it is a suite of tests that test trait Suite itself.

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

Section 14.8

Chapter 14 · Assertions and Unit Testing

308

application. Scala will run this application and pass the remaining tokens as command line arguments. The -p specifies the runpath, which in this case is a JAR file that contains the suite classes: scalatest-1.2-tests.jar. The -s indicates SuiteSuite is the suite to execute. Because you don’t explicitly specify a reporter, you will by default get the graphical reporter. The result is shown in Figure 14.1.

14.8 Conclusion

In this chapter you saw examples of mixing assertions directly in production code as well as writing them externally in unit tests. You saw that as a Scala programmer, you can take advantage of popular testing tools from the Java community, such as JUnit and TestNG, as well as newer tools designed explicitly for Scala, such as ScalaTest, ScalaCheck, and specs. Both in-code assertions and unit testing can help you achieve your software quality goals. We felt that these techniques are important enough to justify the short detour from the Scala tutorial that this chapter represented. In the next chapter, however, we’ll return to the language tutorial and cover a very useful aspect of Scala: pattern matching.

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index