This trait behaves similarly to trait org.scalatest.FeatureSpec, 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.FeatureSpec:

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

Here's an example:

 import org.scalatest.fixture.FixtureFeatureSpec
 import java.io.FileReader
 import java.io.FileWriter
 import java.io.File
 
 class MyFeatureSpec extends FixtureFeatureSpec {

   // 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 scenarios that take a fixture parameter
   feature("Reading and writing files") {
     scenario("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!")
     }
 
     scenario("first char of the temp file") { reader =>
       assert(reader.read() === 'H')
     }
 
     // (You can also write scenarios that don't take a fixture parameter.)
     scenario("no fixture is passed") { () =>
       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.FixtureFeatureSpec
 import scala.collection.mutable.ListBuffer

 class MyFeatureSpec extends FixtureFeatureSpec {

   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)
   }

   scenario("easy") { fixture => 
     val (builder, buffer) = fixture
     builder.append("easy!")
     assert(builder.toString === "ScalaTest is easy!")
     assert(buffer.isEmpty)
     buffer += "sweet"
   }

   scenario("fun") { 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.FixtureFeatureSpec
 import scala.collection.mutable.ListBuffer

 class MyFeatureSpec extends FixtureFeatureSpec {

   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))
   }

   scenario("easy") { fixture =>
     import fixture._
     builder.append("easy!")
     assert(builder.toString === "ScalaTest is easy!")
     assert(buffer.isEmpty)
     buffer += "sweet"
   }

   scenario("fun") { 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 method code can just use them as unqualified identifiers:

 scenario("easy") { 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 method are part of the passed-in fixture:

 scenario("fun") { 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.FixtureFeatureSpec
 import java.io.FileReader
 import java.io.FileWriter
 import java.io.File
 
 class MyFeatureSpec extends FixtureFeatureSpec {

   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()
     }
   }
 
   scenario("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!")
   }
 
   scenario("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.FixtureFeatureSpec
  import org.scalatest.fixture.ConfigMapFixture

  class MyFeatureSpec extends FixtureFeatureSpec with ConfigMapFixture {

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

    scenario("world") { configMap =>
      assert(configMap.contains("world")
    }
  }
 

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