DevOps Zone is brought to you in partnership with:

Jan has posted 2 posts at DZone. View Full User Profile

Top 5 Reasons to Choose ScalaTest Over JUnit

  • submit to reddit

Testing is a major part of our development process. After working with JUnit for some time we leaned back and thought: How can we improve our test productivity? Since we were all fond of Scala we looked at ScalaTest. We liked it from the start so we decided to go with ScalaTest for all new tests. Sure enough there were and are critics in the team who say “I just want to write my tests without having to bother with a new technology…” to convince even the last person on the team I will give you my top 5 reasons to choose ScalaTest over JUnit.

1. Multiple Comparisons

Simple yet very nice is that you can do multiple comparisons for a single object. Say we have a list of books. Now we want to assure that the list contains exactly one book which is our book “Ruling the Universe”. The test code allows us to express it just like that:

books should {
  not be empty and
  have size 1 and
  contain rulingTheUniverse

2. Great DSLs

There are many great DSLs to make the test code much shorter and nicer to read. These DSLs for Scala are much more powerful that those for Java. I will give you just two small examples for Mockito and Selenium.

Mockito Sugar

Say I have a book mock and I want to to check that the method publish has been called exactly once but I don’t care with which arguments. So here you go:

val book = mock[Book]
book expects 'publish withArgs (*) once


We want to open our application in the browser check the title is “Aweseome Books” and then click on the link to explore books. With the Selenium DSL this is expressed like that:

go to "http://localhost/book_app/index.html")
pageTitle should be ("Awesome Books")
click on linkText("Explore ...”)

3. Powerful Matchers

Who needs assertions when you can have matchers? When I started out with ScalaTest I used a lot of assertions because thats what I knew. When I discovered matchers I started to use those as they are much more powerful and have a great syntax which allows you to write your test code very close to the what you actually want to express. I will give just a few examples to give you a first impression of just what you can do with matchers:

Array(3,2,1) should have size 3// check the size of an array
string should include regex "wo.ld"// check string against regular expression
temp should be a 'file // check that temp is a file

4. Tag support

JUnit has categories and ScalaTest has tags. You can tag your tests as you like and the execute only tests with certain tags or do other stuff with the tags. And that’s how you tag a test as “DbTest” and “SlowTest”:

it must "save the book correctly"taggedAs(SlowTest, DbTest) in {
  // call to database

5. JavaBean-style checking of object properties

Say you have a book object with properties such as title and authors. Then you write a test where you want to verify the title is “Ruling the Universe” and it was published in 2012. In JUnit you write assertions like assertEquals(“Ruling the Universe”, book.getTitle()) and you need another assertion for the publication year.

ScalaTest allows for JavaBean-style checking of object properties. So in ScalaTest you can declare the expected values for properties of an object. Instead of the assertions you write the property title of the book should be “Ruling the Universe” and the property publicationYear should be 2012. And thats how this looks in ScalaTest:

book should have (
  ‘title ("Ruling the Universe"),
  ‘author (List("Zaphod", "Ford")),
  ‘publicationYear (2012)

Are you willing to give ScalaTest a try? You should. I like it more and more with every test I write and maybe you will too!

Published at DZone with permission of its author, Jan .

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jean-Baptiste Nizet replied on Sun, 2014/03/23 - 5:59am

Am I the only one to find this a complete nightmare to understand. How is my brain supposed to remember that in the following line:

    go to "http://localhost/book_app/index.html")

you need a closing parenthesis, but no opening one.

But on the following line

     pageTitle should be ("Awesome Books")

you need two perentheses around the string, although in the following line:

    string should include regex "wo.ld"

you don't need any.

And that here you need a single quote:

    temp should be a 'file

but here, you need a curly single quote that I don't even know how to type with my keyboard:

    ‘title ("Ruling the Universe")

IMHO, this is, once again, an abuse of the features of Scala, making tests somewhat easier to read, but impossible to write and understand. I can't imagine how I could be more productive trying to guess what the magical punctuation character I need to add here and there to make the awfully slow Scala compiler happy.

For an easy to use, consistent, extremely readable DSL that doesn't force you to use another test framework and language, Look at fest-assert

Martin Vaněk replied on Sun, 2014/03/23 - 5:20pm in response to: Jean-Baptiste Nizet

I think mostly they are just typos, but even fixed it look like randomly worded rubbish.

Chee Seng Chua replied on Tue, 2014/03/25 - 9:54pm

 It is not really random, the rule (indeed a scala rule) if the total words is even, the bracket is needed at the last word, if it is odd, then the bracket is not needed.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.