Sponsored Link •
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 firstname.lastname@example.org or the ScalaTest gitter channel. Here's the dependency for an sbt build:
libraryDependencies += "org.scalatest" %% "scalatest" % "3.0.0-M11" % "test"
The main difference between M11 and the previous milestone release is that we got rid of the
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
Succeeded was applied like this:
expectMsg(convertToSucceeded("some message"))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
Compatibility traits entirely. The traditional style traits like
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
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
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.
Thanks and happy testing.
|Bill Venners is president of Artima, Inc., publisher of Artima Developer (www.artima.com). He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Active in the Jini Community since its inception, Bill led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill is also the lead developer and designer of ScalaTest, an open source testing tool for Scala and Java developers, and coauthor with Martin Odersky and Lex Spoon of the book, Programming in Scala.|