ScalaTest Release Notes

Changes in 1.4.1 (for Scala 2.9.x)

The goal of the 1.4.1 release is to provide a smooth transition to Scala 2.9.0 for ScalaTest users. It is identical to 1.3 except for changes required to get it to compile as 1.4.1 under Scala 2.9.0, plus one bug fix to the build to ensure the Java portions are cross-compiled for JDK 1.5.

Changed the ScalaTest 1.3 build file to ensure the parts of ScalaTest 1.4.1 written in Java (only two classes) get cross-compiled for JDK 1.5. (This bug fix will also soon be released as ScalaTest 1.3.1. Those two Java classes were accidentally compiled for JDK 1.6 in ScalaTest 1.3.)
Renamed 1.3 to 1.4.1.
Updated the Scala library and compiler to 2.9.0, and the ScalaCheck JAR file to version 1.8 compiled with Scala 2.9.0.
Added the Scala version number to the artifact ID. I.e., the artifact ID for ScalaTest 1.4.1 is scalatest_2.9.0 instead of plain old scalatest.
Recompiled 1.3 to run under 1.4.1.

Note: What happened to 1.4 you ask? We were given an early access release of Scala 2.9.0, so that ScalaTest could be recompiled for it early. We quietly deployed 1.4 so that other projects could be built prior to the official announcement that Scala 2.9.0 was ready. We didn't announce it, but nevertheless someone could have run across it and downloaded it. One day later, we got a brand new Scala 2.9.0. They had fixed a couple show-stopper bugs. We needed to redeploy, so we bumped the version number up to 1.4.1 in case someone had found 1.4 in the meantime. That 1.4 release was then removed from scala-tools.org.

Changes in 1.3 (for Scala 2.8.x)

Improved the sbt support provided by ScalaTestFramework by allowing the formatted output generated by specification-style traits like Spec or WordSpec to be seen by the user when running through sbt. Also enable color output.
Fixed a bug when running suites concurrently that usually manifested itself as an eventual out of memory error. The problem was the executor service being used wasn't being shutdown after each use. So if repeated runs were done in the same JVM, eventually too meany threads would pile up.
Added a SeveredStackTraces stack traces trait that violently chops off test-related stack traces just above the offending line of test code. Although ScalaTest's exception types provide sufficient information to do this when presenting a stack trace to the user, some tools (such as IDEs that run ScalaTest via JUnit) don't use this information yet and therefore show the full stack trace. SeveredStackTraces can be helpful until such tools provide better support for ScalaTest.
Added traits BeforeAndAfterEachFunctions and BeforeAndAfterAllFunctions, which offer a more concise form of before and after functionality (but which can't be stacked or provide access to a config map).
Updated the version of EasyMock to EasyMock 3.0. Unfortuately, EasyMock 3.0 breaks compatibility with previous versions of EasyMock by moving very important types to new packages. So if you're using EasyMock with ScalaTest, you'll need to upgrade to EasyMock 3.0 to use ScalaTest 1.3.
Updated the version of ScalaCheck to 1.8. If you're using ScalaTest with ScalaCheck, you'll likely need to upgrade to ScalaCheck 1.8 to use ScalaTest 1.3.
Added documentation explaining that because Conductor uses the result of calling thread.getState for control flow, occasionally Conductor can produce incorrect results.
Now only use as tags on Suite annotations that are themselves annotated with org.scalatest.TagAnnotation. This is a breaking change that was marked as deprecated since 1.0, and the deprecation cycle has ended.
Added withClue to Assertions to provide a way to supply extra information in an exception thrown by intercept or a ScalaTest matcher expression.
Made assert(a1 === a2) compare arrays structurally. In matcher expressions, the === operator means equality in terms of invoking ==, except for arrays, for which == checks that the two arrays are the same instance. For arrays, ScalaTest matchers passes the two arrays to java.util.Arrays.deepEquals. Now === has the same behavior for arrays when used in an assertion. As a result, the === operator now always compares arrays structurally no matter how it is used in ScalaTest. Note, this change would break any code that was intentionally using === to ensure two arrays are the same instance in an assert. It is likely no one was actually doing that, but if so, this will show up as a failed test and that code will need to be changed to assert(a1 eq a2). (Sorry, there was no way to deprecate a particular use of ===.)