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?

Last week I released a new version of ScalaTest (0.9.5) that includes a "matchers DSL" for writing more expressive assertions in tests. In this post I show differences between ScalaTest matchers and those in Ruby's RSpec tool, and discuss some of the general differences in DSL creation in Ruby and Scala.

The next version of ScalaTest will include a set of matchers. These matchers demonstrate the kind of DSL notation you can create in Scala. In this post, I give a sneak preview of ScalaTest matchers, and ask for feedback.

The latest version of ScalaTest includes a trait named SpecDasher, which when mixed into a Spec facilitates a more concise expression of specification-style tests. It is deprecated, however, and may be removed in a future release depending on user feedback. What's your opinion?

The latest version of ScalaTest, a testing tool for Scala and Java developers, includes a concise way to test private methods and support for behavior-driven development.

Artima's first published book, Programming in Scala, made its bookstore debut last week at the Devoxx conference in Antwerp, Belgium, where it sold out. Twice.

In the most recent release of ScalaTest, I've placed some guidelines in the documentation for how to avoid the use of vars in testing code. In this post I include those guidelines and ask for feedback.

Tonight I released a new version of ScalaTest, which contains a few changes to the way in which you express assertions and a Suite discovery feature. This release contains all the features that I plan to have in version 1.0, so it is ready for a few months of beta testing.

Today I released a testing tool written in Scala, which can be used to test Scala or Java code. It is intended primarily as a tool for testing Scala code, but can also be used as a low-risk way to get started programming in Scala, by writing tests in Scala for production code written in Java.