I'm using ScalaTest 2.0.0.M4 to test a Play app, both from IDEA and SBT.
 Play 2.0 uses a system property which you can define on the command line
with -Dconfig.file=conf/test.conf to override the default
conf/application.conf.  I find it important to always use a test.conf so
that only test databases will be used.  In IDEA I simply provide -Dk=v in
the VM options.  In SBT, however, the property will be set in the current
JVM, so I have to set it initially and then set and restore it around
tests, like this:

    initialize ~= { _ =>
      System.setProperty("config.file", "conf/dev.conf")
    },
    testOptions in Test ++= Seq( Tests.Setup{ () =>
System.setProperty("config.file", "conf/test.conf") }, Tests.Cleanup{ () =>
System.setProperty("config.file", "conf/dev.conf")})

(I'd need to set yet another configuration file for the dist task, and
ensure it is set around dist...)  When researching setting properties in
SBT, I've found the recommendation to use the test frameworks' own options.
 Config maps looked exactly like that, but they seem not to affect the
system properties.  E.g., this didn't seem to work:

    testOptions in Test += Tests.Argument(TestFrameworks.ScalaTest,
"-Dconfig.file=conf/test.conf")

What are the config maps used for, and what's the recommended way to set
the system properties in SBT?  Can they be specified as a part of the tests
themselves in a general way, e.g. via importing a setting?

A+

ScalaTest's config map is independent from system properties. I'm not
sure if there's a better way to do what you are doing with sbt. That's
probably better asked on the sbt mailing list than here. But you could
also possibly do this inside your tests themselves.

I'm not sure what other setup is going on in your tests, but if you
can change that system property for each test, you could create a
trait with a withFixture(NoArgTest) that sets the system property
before each test and resets it after. You could mix that trait into
each test class.

Bill