A suite of tests in which each test is represented as a function value. The “Fun ”in FunSuite stands for functional. Here's an example FunSuite:

 import org.scalatest.fun.FunSuite

 class MySuite extends FunSuite {

   test("addition") {
     val sum = 1 + 1
     assert(sum === 2)
     assert(sum + 2 === 4)
   }

   test("subtraction") {
     val diff = 4 - 1
     assert(diff === 3)
     assert(diff - 2 === 1)
   }
 }
 

“test” is a method defined in FunSuite, which will be invoked by the primary constructor of MySuite. You specify the name of the test as a string between the parentheses, and the test code itself between curly braces. The test code is a function passed as a by-name parameter to test, which registers it for later execution. One benefit of FunSuite compared to Suite is you need not name all your tests starting with “test.” In addition, you can more easily give long names to your tests, because you need not encode them in camel case, as you must do with test methods.

A suite of tests in which each test is represented as a function value that takes 1 parameter that is intended to serve as a fixture object for the suite's tests. Clients must parameterize FunSuite1 with the type of the fixture object. Most often this will be done explicitly by subclasses that have tests that need the fixture object. Here's an example:

 class MySuite extends FunSuite1[Float] {

   testWithFixture("example test") {
     (f) => {
       // test code that uses the passed fixture object...
     }
   }

   def withFixture(f: (Float) => Unit) {

      // Create the fixture objects (as in JUnit 3's setUp method)
      val f = 1.1f

      // Pass the fixture objects to the test function
      f(f)

      // If need be, perform any cleanup (as in JUnit 3's tearDown method)
   }
 }
 

This is a contrived example, because normally you would only pass fixture objects in this manner if they are mutable. (The reason we used immutable objects in this example was just to make the type names fit more easily on the page.) If they aren't mutable, then the fixture objects can simply be referenced from instance variables and shared by all test methods that need them. Since they aren't mutable, they can't be "corrupted" by one test and rendered unusable by the next. For mutable fixture objects, though, this trait allows you to reinitialize and pass in a fresh set of fixture objects to each test function that needs them.

A suite of tests in which each test is represented as a function value that takes 2 parameters that are intended to serve as fixture objects for the suite's tests. Clients must parameterize FunSuite2 with the types of each of the fixture objects. Most often this will be done explicitly by subclasses that have tests that need the fixture objects. Here's an example:

 class MySuite extends FunSuite2[Float, Int] {

   testWithFixture("example test") {
     (f, i) => {
       // test code that uses the passed fixture objects...
     }
   }

   def withFixture(f: (Float, Int) => Unit) {

      // Create the fixture objects (as in JUnit 3's setUp method)
      val f = 1.1f
      val float = 1.1f

      // Pass the fixture objects to the test function
      f(f, i)

      // If need be, perform any cleanup (as in JUnit 3's tearDown method)
   }
 }
 

This is a contrived example, because normally you would only pass fixture objects in this manner if they are mutable. (The reason we used immutable objects in this example was just to make the type names fit more easily on the page.) If they aren't mutable, then the fixture objects can simply be referenced from instance variables and shared by all test methods that need them. Since they aren't mutable, they can't be "corrupted" by one test and rendered unusable by the next. For mutable fixture objects, though, this trait allows you to reinitialize and pass in a fresh set of fixture objects to each test function that needs them.

A suite of tests in which each test is represented as a function value that takes 3 parameters that are intended to serve as fixture objects for the suite's tests. Clients must parameterize FunSuite3 with the types of each of the fixture objects. Most often this will be done explicitly by subclasses that have tests that need the fixture objects. Here's an example:

 class MySuite extends FunSuite3[Float, Int, Long] {

   testWithFixture("example test") {
     (f, i, x) => {
       // test code that uses the passed fixture objects...
     }
   }

   def withFixture(f: (Float, Int, Long) => Unit) {

      // Create the fixture objects (as in JUnit 3's setUp method)
      val f = 1.1f
      val i = 7
      val x = 21L

      // Pass the fixture objects to the test function
      f(f, i, x)

      // If need be, perform any cleanup (as in JUnit 3's tearDown method)
   }
 }
 

This is a contrived example, because normally you would only pass fixture objects in this manner if they are mutable. (The reason we used immutable objects in this example was just to make the type names fit more easily on the page.) If they aren't mutable, then the fixture objects can simply be referenced from instance variables and shared by all test methods that need them. Since they aren't mutable, they can't be "corrupted" by one test and rendered unusable by the next. For mutable fixture objects, though, this trait allows you to reinitialize and pass in a fresh set of fixture objects to each test function that needs them.

A suite of tests in which each test is represented as a function value that takes 4 parameters that are intended to serve as fixture objects for the suite's tests. Clients must parameterize FunSuite4 with the types of each of the fixture objects. Most often this will be done explicitly by subclasses that have tests that need the fixture objects. Here's an example:

 class MySuite extends FunSuite4[Float, Int, Long, String] {

   testWithFixture("example test") {
     (f, i, x, t) => {
       // test code that uses the passed fixture objects...
     }
   }

   def withFixture(f: (Float, Int, Long, String) => Unit) {

      // Create the fixture objects (as in JUnit 3's setUp method)
      val f = 1.1f
      val i = 7
      val x = 21L
      val t = "hi"

      // Pass the fixture objects to the test function
      f(f, i, x, t)

      // If need be, perform any cleanup (as in JUnit 3's tearDown method)
   }
 }
 

This is a contrived example, because normally you would only pass fixture objects in this manner if they are mutable. (The reason we used immutable objects in this example was just to make the type names fit more easily on the page.) If they aren't mutable, then the fixture objects can simply be referenced from instance variables and shared by all test methods that need them. Since they aren't mutable, they can't be "corrupted" by one test and rendered unusable by the next. For mutable fixture objects, though, this trait allows you to reinitialize and pass in a fresh set of fixture objects to each test function that needs them.

A suite of tests in which each test is represented as a function value that takes 5 parameters that are intended to serve as fixture objects for the suite's tests. Clients must parameterize FunSuite5 with the types of each of the fixture objects. Most often this will be done explicitly by subclasses that have tests that need the fixture objects. Here's an example:

 class MySuite extends FunSuite5[Float, Int, Long, String, Boolean] {

   testWithFixture("example test") {
     (f, i, x, t, ) => {
       // test code that uses the passed fixture objects...
     }
   }

   def withFixture(f: (Float, Int, Long, String, Boolean) => Unit) {

      // Create the fixture objects (as in JUnit 3's setUp method)
      val f = 1.1f
      val i = 7
      val x = 21L
      val t = "hi"
      val u = true

      // Pass the fixture objects to the test function
      f(f, i, x, t, )

      // If need be, perform any cleanup (as in JUnit 3's tearDown method)
   }
 }
 

This is a contrived example, because normally you would only pass fixture objects in this manner if they are mutable. (The reason we used immutable objects in this example was just to make the type names fit more easily on the page.) If they aren't mutable, then the fixture objects can simply be referenced from instance variables and shared by all test methods that need them. Since they aren't mutable, they can't be "corrupted" by one test and rendered unusable by the next. For mutable fixture objects, though, this trait allows you to reinitialize and pass in a fresh set of fixture objects to each test function that needs them.

A suite of tests in which each test is represented as a function value that takes 6 parameters that are intended to serve as fixture objects for the suite's tests. Clients must parameterize FunSuite6 with the types of each of the fixture objects. Most often this will be done explicitly by subclasses that have tests that need the fixture objects. Here's an example:

 class MySuite extends FunSuite6[Float, Int, Long, String, Boolean, Short] {

   testWithFixture("example test") {
     (f, i, x, t, u, r) => {
       // test code that uses the passed fixture objects...
     }
   }

   def withFixture(f: (Float, Int, Long, String, Boolean, Short) => Unit) {

      // Create the fixture objects (as in JUnit 3's setUp method)
      val f = 1.1f
      val i = 7
      val x = 21L
      val t = "hi"
      val u = true, val r = 2

      // Pass the fixture objects to the test function
      f(f, i, x, t, u, r)

      // If need be, perform any cleanup (as in JUnit 3's tearDown method)
   }
 }
 

This is a contrived example, because normally you would only pass fixture objects in this manner if they are mutable. (The reason we used immutable objects in this example was just to make the type names fit more easily on the page.) If they aren't mutable, then the fixture objects can simply be referenced from instance variables and shared by all test methods that need them. Since they aren't mutable, they can't be "corrupted" by one test and rendered unusable by the next. For mutable fixture objects, though, this trait allows you to reinitialize and pass in a fresh set of fixture objects to each test function that needs them.

A suite of tests in which each test is represented as a function value that takes 7 parameters that are intended to serve as fixture objects for the suite's tests. Clients must parameterize FunSuite7 with the types of each of the fixture objects. Most often this will be done explicitly by subclasses that have tests that need the fixture objects. Here's an example:

 class MySuite extends FunSuite7[Float, Int, Long, String, Boolean, Short, Double] {

   testWithFixture("example test") {
     (f, i, x, t, u, r, e) => {
       // test code that uses the passed fixture objects...
     }
   }

   def withFixture(f: (Float, Int, Long, String, Boolean, Short, Double) => Unit) {

      // Create the fixture objects (as in JUnit 3's setUp method)
      val f = 1.1f
      val i = 7
      val x = 21L
      val t = "hi"
      val u = true
      val r = 2
      val e = 2.0

      // Pass the fixture objects to the test function
      f(f, i, x, t, u, r, e)

      // If need be, perform any cleanup (as in JUnit 3's tearDown method)
   }
 }
 

This is a contrived example, because normally you would only pass fixture objects in this manner if they are mutable. (The reason we used immutable objects in this example was just to make the type names fit more easily on the page.) If they aren't mutable, then the fixture objects can simply be referenced from instance variables and shared by all test methods that need them. Since they aren't mutable, they can't be "corrupted" by one test and rendered unusable by the next. For mutable fixture objects, though, this trait allows you to reinitialize and pass in a fresh set of fixture objects to each test function that needs them.

A suite of tests in which each test is represented as a function value that takes 8 parameters that are intended to serve as fixture objects for the suite's tests. Clients must parameterize FunSuite8 with the types of each of the fixture objects. Most often this will be done explicitly by subclasses that have tests that need the fixture objects. Here's an example:

 class MySuite extends FunSuite8[Float, Int, Long, String, Boolean, Short, Double, Byte] {

   testWithFixture("example test") {
     (f, i, x, t, u, r, e, o) => {
       // test code that uses the passed fixture objects...
     }
   }

   def withFixture(f: (Float, Int, Long, String, Boolean, Short, Double, Byte) => Unit) {

      // Create the fixture objects (as in JUnit 3's setUp method)
      val f = 1.1f
      val i = 7
      val x = 21L
      val t = "hi"
      val u = true
      val r = 2
      val e = 2.0
      val o = 128

      // Pass the fixture objects to the test function
      f(f, i, x, t, u, r, e, o)

      // If need be, perform any cleanup (as in JUnit 3's tearDown method)
   }
 }
 

This is a contrived example, because normally you would only pass fixture objects in this manner if they are mutable. (The reason we used immutable objects in this example was just to make the type names fit more easily on the page.) If they aren't mutable, then the fixture objects can simply be referenced from instance variables and shared by all test methods that need them. Since they aren't mutable, they can't be "corrupted" by one test and rendered unusable by the next. For mutable fixture objects, though, this trait allows you to reinitialize and pass in a fresh set of fixture objects to each test function that needs them.

A suite of tests in which each test is represented as a function value that takes 9 parameters that are intended to serve as fixture objects for the suite's tests. Clients must parameterize FunSuite9 with the types of each of the fixture objects. Most often this will be done explicitly by subclasses that have tests that need the fixture objects. Here's an example:

 class MySuite extends FunSuite9[Float, Int, Long, String, Boolean, Short, Double, Byte, String] {

   testWithFixture("example test") {
     (f, i, x, t, u, r, e, o, b) => {
       // test code that uses the passed fixture objects...
     }
   }

   def withFixture(f: (Float, Int, Long, String, Boolean, Short, Double, Byte, String) => Unit) {

      // Create the fixture objects (as in JUnit 3's setUp method)
      val f = 1.1f
      val i = 7
      val x = 21L
      val t = "hi"
      val u = true
      val r = 2
      val e = 2.0
      val o = 128
      val b = "fixtures are easy!"

      // Pass the fixture objects to the test function
      f(f, i, x, t, u, r, e, o, b)

      // If need be, perform any cleanup (as in JUnit 3's tearDown method)
   }
 }
 

This is a contrived example, because normally you would only pass fixture objects in this manner if they are mutable. (The reason we used immutable objects in this example was just to make the type names fit more easily on the page.) If they aren't mutable, then the fixture objects can simply be referenced from instance variables and shared by all test methods that need them. Since they aren't mutable, they can't be "corrupted" by one test and rendered unusable by the next. For mutable fixture objects, though, this trait allows you to reinitialize and pass in a fresh set of fixture objects to each test function that needs them.

Abstract class whose subclasses can be as to FunSuite and FunSuiteN's test registration methods to place tests into groups. For example, if you define:

 object SlowTest extends Group("SlowTest")
 

then you can place a test into the SlowTest group like this:

 class MySuite extends FunSuite {

   test("my test", SlowTest) {
     Thread.sleep(1000)
   }
 }
 

If you have created Java annotation interfaces for use as group names in direct subclasses of org.scalatest.Suite, then you will probably want to use group names on your FunSuites that match. To do so, simply pass the fully qualified names of the Java interfaces to the Group constructor. For example, if you've defined a Java annotation interface with fully qualified name, com.mycompany.groups.SlowTest, then you could create a matching group for FunSuites like this:

 object SlowTest extends Group("com.mycompany.groups.SlowTest")