Today we released ScalaTest/Scalactic 3.0.0-M11, which includes a significant reorganization inspired by feedback from the 3.0.0-M10 release two weeks ago.
Today I released ScalaTest and Scalactic 3.0.0-M10 for Scala 2.10 and 2.11 and Scala.js 0.9.5. If you have time please try this release out on your projects and post feedback to email@example.com or the ScalaTest gitter channel. Here's the dependency for an sbt build:
The main difference between M11 and the previous milestone release is that we got rid of the Safety and Compatibility implicit conversions, because a few users reported that expectMsg calls were failing. This method has the following signature:
def expectMsg[T](o: T): T
The problem occurred because the Compatibility implicit conversion from Any to Succeeded was applied like this:
Instead of like this:
This meant that you were now expecting Succeeded to be the message instead of "some message". It compiled, but failed the test. So that approach was not going to work.
Instead, we got rid of the Safety and Compatibility traits entirely. The traditional style traits like FunSuite, FlatSpec, etc., went back to taking plain old Unit like before. So those will stay compatible with existing code. They will work in 3.0 exactly like they do in 2.0. The async styles, new in 3.0, now require Future[Assertion] without offering any implicit conversions to automatically convert other types to Future[Assertion]. So the new async styles will be more strict than traditional styles.
We have also added a set of "safe" styles, named SafeFunSuite, SafeFlatSpec, etc., that work exactly like traditional styles except tests require result type Assertion. This extra batch of styles is the API surface area we were trying to avoid with the Safety and Compatibility implicits. We have not done so for 3.0.0-M11, but we plan to modularize the 3.0.0-final release so that you can, if you prefer, just depend on the parts of ScalaTest you use. If you just use the FlatSpec style with assertions, for example, you can depend on the scalatest-flatspec artifact. If you also want matchers, you depend on scalatest-matchers as well, and you'd just get "should" matchers not "must" matchers. If you don't care about that, you can just continue to depend on the scalatest artifact, and it will continue to include everything as it does now.
For more insight into the coming 3.0 release, see the earlier ScalaTest 3.0 Preview post about 3.0.0-M10.
> when is there a plan to have scalatest run natively in > eclipse code coverage? > > Its a BUMMER that we have to convert it to run as a junit > test just to get coverage results > We hadn't heard about that. That does sound like a bummer. Got lots on our plate, so not sure about when, but you did just put it on the radar.