ScalaTest 1.7.2 is identical to 1.7.1 except for two changes: the argument "sequential" is ignored to facilitate Play 2.0 integration and a bug in the ScalaTest Framework has been fixed. The bug that was fixed was that when running with sbt, ScalaTest would keep a thread going after the tests were completed. This thread is now not created in the first place.
ScalaTest 1.7.1 is identical to 1.7 except for one change: the Guice dependency in the pom.xml file has been made optional. This minor pom file error in 1.7 unfortunately caused a much more serious deployment problem: the wrong jar files were deployed to scala-tools.org (mirrored on Maven Central) under artifact IDs scalatest_2.8.2, scalatest_2.9.0-1, and scalatest_2.9.1. The jar files for 1.7.RC2 were incorrectly deployed instead. We redeployed correct 1.7 jar files over the top as soon as we discovered the problem, but because the incorrect jars escaped and were in the repository for a while we released 1.7.1 one day later so people can be sure they are getting good jar files from the Maven repositories.
To see the changes in 1.7.1 from the previous releases (1.6.1 and 1.5.1), therefore, look at the release notes for 1.7.
ScalaTest 1.7 is source (but not necessarily binary) compatible with previous releases. To upgrade from 1.5.1 or 1.6.1, you should only need to do a clean build.
This release includes the following enhancements, bug fixes, dependency changes, and deprecations:
Inside, which lets you make assertions about values extracted from an object via a pattern match
PartialFunctionValues, which allow you to make one-liner assertions about values that should exist in
MockitoSugarfor new mock methods added to
WrapWithannotation to enable ScalaTest to run non-
Suites, similar to JUnit's
NonImplicitAssertions, which turns off the lone implicit conversion you get by default in a ScalaTest suite
Ordinalserializable, as well as internal implementations of
Rerunner, to make it easier to run tests in a different VM across a network
MockitoSugar, selfless traits
OneInstancePerTestreport tests tagged as ignored as Ignored rather than running them. To fix this, had to change the semantics of run slightly, but in a way that is unlikely to break any user code. Now if you pass the name of a test marked as ignored to
Suite.run, the test will be reported as ignored. Previously it would be run even though it was marked as ignored. So now ignore always means ignore (and that is arguably an improvement because it is more consistent). The upshot is that if you want to run a test marked as ignored, you need to take the ignore annotation off, then run it.
"!!! Suite Aborted !!!"in the case of a
SuiteAbortedevent when running with sbt. Will eventually help enhance sbt's
Frameworkto do this the right way, but for now, at least sbt won't think that nothing went wrong.
GeneratorDrivenPropertyChecks. Previously if you supplied generator, name string tuples to
forAll, and the property check failed, the names you supplied wouldn't show up in the error message. Instead the error message would just show generic names
arg1,etc. Now it shows the supplied names.
Runner, for running TestNG test suites (-t will still work during deprecation cycle, but you'll get a deprecation warning.)
Rerunnerwith a note asking if anyone is using it. If we don't hear back that anyone is using it, there's a good chance we'll remove it in 2.0 (
Rerunnerwill still work during deprecation cycle, but you'll get a deprecation warning.)
org.scalatest.fixture.FixtureXin favor of
fixture.FunSuite, etc. (The old names will still work during deprecation cycle, but you'll get a deprecation warning until you change the names.)
thatin favor of
thatwill still work during the deprecation cycle, but you'll get a deprecation warning until you change uses to
which. We plan to reuse
thatfor a different purpose in the future.)
org.scalatest.Specin favor of
org.scalatest.fixture.FixtureSpecin favor of
org.scalatest.fixture.FunSpec. (The old names will still work during the deprecation cycle, but you'll get a deprecation warning. We plan to reuse
Specfor a different purpose in the future.)