This trait behaves similarly to trait org.scalatest.Spec, except that tests may take a fixture object. The type of the fixture object passed is defined by the abstract Fixture type, which is declared as a member of this trait (inherited from supertrait FixtureSuite). This trait also inherits the abstract method withFixture from supertrait FixtureSuite. The withFixture method takes a OneArgTest, which is a nested trait defined as a member of supertrait FixtureSuite. OneArgTest has an apply method that takes a Fixture. This apply method is responsible for running a test. This trait's runTest method delegates the actual running of each test to withFixture, passing in the test code to run via the OneArgTest argument. The withFixture method (abstract in this trait) is responsible for creating the fixture and passing it to the test function.

Subclasses of this trait must, therefore, do three things differently from a plain old org.scalatest.Spec:

1. define the type of the fixture object by specifying type Fixture
2. define the withFixture method
3. write tests that take a Fixture (You can also define tests that don't take a Fixture.)

Here's an example:

 import org.scalatest.fixture.FixtureSpec
 import java.io.FileReader
 import java.io.FileWriter
 import java.io.File
 
 class MySpec extends FixtureSpec {

   // 1. define type FixtureParam
   type FixtureParam = FileReader

   // 2. define the withFixture method
   def withFixture(test: OneArgTest) {

     val FileName = "TempFile.txt"

     // Set up the temp file needed by the test
     val writer = new FileWriter(FileName)
     try {
       writer.write("Hello, test!")
     }
     finally {
       writer.close()
     }

     // Create the reader needed by the test
     val reader = new FileReader(FileName)
  
     try {
       // Run the test using the temp file
       test(reader)
     }
     finally {
       // Close and delete the temp file
       reader.close()
       val file = new File(FileName)
       file.delete()
     }
   }
 
   // 3. write tests that take a fixture parameter
   it("should read from the temp file") { reader =>
     var builder = new StringBuilder
     var c = reader.read()
     while (c != -1) {
       builder.append(c.toChar)
       c = reader.read()
     }
     assert(builder.toString === "Hello, test!")
   }
 
   it("should read the first char of the temp file") { reader =>
     assert(reader.read() === 'H')
   }
 
   // (You can also write tests that don't take a fixture parameter.)
   it("should work without a fixture") { () =>
       assert(1 + 1 === 2)
   }
 }
 

If the fixture you want to pass into your tests consists of multiple objects, you will need to combine them into one object to use this trait. One good approach to passing multiple fixture objects is to encapsulate them in a tuple. Here's an example that takes the tuple approach:

 import org.scalatest.fixture.FixtureSpec
 import scala.collection.mutable.ListBuffer

 class MySpec extends FixtureSpec {

   type FixtureParam = (StringBuilder, ListBuffer[String])

   def withFixture(test: OneArgTest) {

     // Create needed mutable objects
     val stringBuilder = new StringBuilder("ScalaTest is ")
     val listBuffer = new ListBuffer[String]

     // Invoke the test function, passing in the mutable objects
     test(stringBuilder, listBuffer)
   }

   it("should mutate shared fixture objects") { fixture =>
     val (builder, buffer) = fixture
     builder.append("easy!")
     assert(builder.toString === "ScalaTest is easy!")
     assert(buffer.isEmpty)
     buffer += "sweet"
   }

   it("should get a fresh set of mutable fixture objects") { fixture =>
     val (builder, buffer) = fixture
     builder.append("fun!")
     assert(builder.toString === "ScalaTest is fun!")
     assert(buffer.isEmpty)
   }
 }
 

When using a tuple to pass multiple fixture objects, it is usually helpful to give names to each individual object in the tuple with a pattern-match assignment, as is done at the beginning of each test here with:

 val (builder, buffer) = fixture
 

Another good approach to passing multiple fixture objects is to encapsulate them in a case class. Here's an example that takes the case class approach:

 import org.scalatest.fixture.FixtureSpec
 import scala.collection.mutable.ListBuffer

 class MySpec extends FixtureSpec {

   case class FixtureHolder(builder: StringBuilder, buffer: ListBuffer[String])

   type FixtureParam = FixtureHolder

   def withFixture(test: OneArgTest) {

     // Create needed mutable objects
     val stringBuilder = new StringBuilder("ScalaTest is ")
     val listBuffer = new ListBuffer[String]

     // Invoke the test function, passing in the mutable objects
     test(FixtureHolder(stringBuilder, listBuffer))
   }

   it("should mutate shared fixture objects") { fixture =>
     import fixture._
     builder.append("easy!")
     assert(builder.toString === "ScalaTest is easy!")
     assert(buffer.isEmpty)
     buffer += "sweet"
   }

   it("should get a fresh set of mutable fixture objects") { fixture =>
     fixture.builder.append("fun!")
     assert(fixture.builder.toString === "ScalaTest is fun!")
     assert(fixture.buffer.isEmpty)
   }
 }
 

When using a case class to pass multiple fixture objects, it can be helpful to make the names of each individual object available as a single identifier with an import statement. This is the approach taken by the testEasy method in the previous example. Because it imports the members of the fixture object, the test code can just use them as unqualified identifiers:

 it("should mutate shared fixture objects") { fixture =>
   import fixture._
   builder.append("easy!")
   assert(builder.toString === "ScalaTest is easy!")
   assert(buffer.isEmpty)
   buffer += "sweet"
 }
 

Alternatively, you may sometimes prefer to qualify each use of a fixture object with the name of the fixture parameter. This approach, taken by the testFun method in the previous example, makes it more obvious which variables in your test are part of the passed-in fixture:

 it("should mutate shared fixture objects") { fixture =>
   fixture.builder.append("fun!")
   assert(fixture.builder.toString === "ScalaTest is fun!")
   assert(fixture.buffer.isEmpty)
 }
 

Configuring fixtures and tests

Sometimes you may want to write tests that are configurable. For example, you may want to write a suite of tests that each take an open temp file as a fixture, but whose file name is specified externally so that the file name can be can be changed from run to run. To accomplish this the OneArgTest trait has a configMap method, which will return a Map[String, Any] from which configuration information may be obtained. The runTest method of this trait will pass a OneArgTest to withFixture whose configMap method returns the configMap passed to runTest. Here's an example in which the name of a temp file is taken from the passed configMap:

 import org.scalatest.fixture.FixtureSpec
 import java.io.FileReader
 import java.io.FileWriter
 import java.io.File
 
 class MySpec extends FixtureSpec {

   type FixtureParam = FileReader

   def withFixture(test: OneArgTest) {

     require(
       test.configMap.contains("TempFileName"),
       "This suite requires a TempFileName to be passed in the configMap"
     )

     // Grab the file name from the configMap
     val FileName = test.configMap("TempFileName")

     // Set up the temp file needed by the test
     val writer = new FileWriter(FileName)
     try {
       writer.write("Hello, test!")
     }
     finally {
       writer.close()
     }

     // Create the reader needed by the test
     val reader = new FileReader(FileName)
  
     try {
       // Run the test using the temp file
       test(reader)
     }
     finally {
       // Close and delete the temp file
       reader.close()
       val file = new File(FileName)
       file.delete()
     }
   }
 
   test("reading from the temp file") { reader =>
     var builder = new StringBuilder
     var c = reader.read()
     while (c != -1) {
       builder.append(c.toChar)
       c = reader.read()
     }
     assert(builder.toString === "Hello, test!")
   }
 
   test("first char of the temp file") { reader =>
     assert(reader.read() === 'H')
   }
 }
 

If you want to pass into each test the entire configMap that was passed to runTest, you can mix in trait ConfigMapFixture. See the documentation for ConfigMapFixture for the details, but here's a quick example of how it looks:

  import org.scalatest.fixture.FixtureSpec
  import org.scalatest.fixture.ConfigMapFixture

  class MySpec extends FixtureSpec with ConfigMapFixture {

    it("should contain hello") { configMap =>
      // Use the configMap passed to runTest in the test
      assert(configMap.contains("hello")
    }

    it("should contain world") { configMap =>
      assert(configMap.contains("world")
    }
  }
 

ConfigMapFixture can also be used to facilitate writing FixtureSpecs that include tests that take different fixture types. See the documentation for MultipleFixtureSpec for more information.