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.

The 3.0.0 release of ScalaTest is coming soon. It is a major release with significant new features. In this post, I give a preview of the new features, and ask for feedback.

The 2.0.M6 milestone release of ScalaTest is coming soon. It is a major release with many new features. In this post, I give a preview of the new features, and ask for feedback.

Today I released a candidate for the next version of ScalaTest for Scala 2.9.0, ScalaTest 1.6.1.RC1. This release includes all the enhancements of ScalaTest 1.5, plus one new trait, BeforeAndAfter, a few deprecations, and improved documentation.

The ScalaTest Shell is a new DSL coming in ScalaTest 1.5 that aims to make ScalaTest easier to use from the Scala interpreter. This post gives preview.

Today I released a new ScalaTest-1.5 snapshot release that contains several enhancements, including formatted output for TDD-style traits, indented output for nested style traits, and two new style traits, PropSpec and FreeSpec.

The next release of ScalaTest will offer a unified API for table- and generator-driven property checks. This blog post gives a preview.

Artima has published its second book, Flex 4 Fun by Chet Haase. This book covers the graphics and animation parts of Flex 4: the fun stuff! Along the way it gives many insights and tips on how to use graphics and animation to create better users experiences.

Today I gave a presentation about ScalaTest at a local company. I showed ways ScalaTest integrates with JUnit and makes it easier to do some things that are harder to do with JUnit in Java. It made me curious to find out what JUnit users would say are their actual pain points today with JUnit.

In this blog, I attempt to answer a common question among Scala programmers: when would I opt to use an abstract type member instead of a generic type parameter in Scala API design?

At the JVM Languages Summit, Josh Bloch expressed his concern about what he called the "semantic gap" between the source code we write and its performance at runtime: As performance improves, our ability to predict the performance consequences of our source code degrades.

Scala has an Option type that provides a type-safe alternative to using null to represent optional values. In this blog post, I show how to replace nested conditionals involving Option with a for-expression.

A recent paper by Gilles Dubochet describes a study that concluded Scala code written in a functional style that favors for expressions and higher order functions is easier to comprehend than Scala code written in a more Java-like, looping style. It also found that meaningful variable names were insigificant or even detrimental to comprehension.

In "The Feel of Scala," a talk I gave at Devoxx which is now available on Parleys.com, I show Scala solutions to real problems to help you get a feel for the language. Along the way I demonstrate how you can get many of the productivity benefits offered by dynamic languages using alternative static techniques in Scala.

I've observed two, often competing aspects of code readability: clarity of the programmer's intent (the "what") and clarity of the implementation (the "how"). What does code readability mean to you, and what do you think is the best way to maximize it?