Over a million developers have joined DZone.

Top 5 Reasons to Choose ScalaTest Over JUnit

DZone's Guide to

Top 5 Reasons to Choose ScalaTest Over JUnit

· DevOps Zone ·
Free Resource

DevOps involves integrating development, testing, deployment and release cycles into a collaborative process. Learn more about the 4 steps to an effective DevSecOps infrastructure.

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!

Read the 4-part DevOps testing eBook to learn how to detect problems earlier in your DevOps testing processes.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}