published on in intro testing

Testing our Scala code

Why test our code?

This is a more ‘practical’ topic, and I’m sure that many would argue that learning how to use a unit testing framework is not strictly necessary for newcomers. But according to my experience, getting into the habit of writing tests regularly quickly pays off.

Why? It’s nicely summarized here, I’m just listing here the main points:

  1. Regression Testing
  2. Improve The Implementation Via New Insights
  3. It Saves Time, Really
  4. Self-Updating Documentation
  5. It Is Fun

Testing frameworks for Scala

In Scala, you basically have two main-stream options if you want to write unit tests for your code:

We’ll explore the first one, the ScalaTest framework in this short post, through some basic examples.

A simple test with ScalaTest

To use ScalaTest we need to add it as a dependency to our build.sbt file in the root of our sbt project. (Note: If you don’t know how to set up a Scala project with SBT, you can find help here)

We’ll need to extend our initial build.sbt with a new libraryDepencencies part. (Note: If you already had dependencies in the libraryDependencies section, then just add a new line to let SBT know that we want to use the ScalaTest framework. But be careful, all, but the last line within the Seq should end in a comma!)

name := "my_tested_app"
version := "0.1"
exportJars := true
scalaVersion := "2.11.7"
libraryDependencies ++= {
  Seq(
    "org.scalatest"       %%  "scalatest" % "2.2.6" % "test"
  )
}
In the above example, we tell SBT that we want to use the ScalaTest framework, version 2.6.6, so it will download all the necessary things at the first subsequent ‘sbt build’ or ‘sbt run’ or ‘sbt test’ command.

Where do we put our test codes?

Usually another directory with the name ‘test’ is created next to the ‘main’ source folder within the project’s ‘src’ folder, that contains all the source codes. Inside these, a parallel directory structure is used to hold the packages which group together our scala files. (More about packages in a later post.)

See an example here.

If you use this standard layout for your source codes, then SBT will automatically explore your tests, and you’ll be able to run all of them simply via the ‘sbt test’ command. But we jumped a bit ahead :)

At first let’s write a test. We need to create a new file within the ‘test’ directory.

import org.scalatest.FlatSpec

class MyTest extends FlatSpec {

  "This example test" should "pass" in {
    assert(2 == 1 + 2)
  }
}

Let’s save it as ‘src/test/scala/MyFirstTest.scala’ within your project folder.

Running our tests

And now let’s see if it works: type into the console, while in the root of your SBT project:

sbt test

Of course, the above test will fail:

...
[info] *** 1 TEST FAILED ***
[error] Failed tests:
[error] 	MyTest
[error] (test:test) sbt.TestsFailedException: Tests unsuccessful
[error] Total time: 4 s, completed May 13, 2016 6:00:22 PM

Because… oh yes, 1+2 does not equal to 2. I just wanted to show a failing test at first. Now let’s fix it, and maybe add another test:

import org.scalatest.FlatSpec

class MyTest extends FlatSpec {

  "This example test" should "pass" in {
    assert(3 == 1 + 2)
  }

  "This second example test" should "also pass" in {
    assert(3 > 2)
  }
}

After re-running ‘sbt test’:

[info] MyTest:
[info] This example test
[info] - should pass
[info] This second test
[info] - should also pass
[info] Run completed in 216 milliseconds.
[info] Total number of tests run: 2
[info] Suites: completed 1, aborted 0
[info] Tests: succeeded 2, failed 0, canceled 0, ignored 0, pending 0
[info] All tests passed.
[success] Total time: 5 s, completed May 13, 2016 6:08:34 PM

This is it!

Another example, related to the last example of the previous post.

Note n+1 : Until I set up a comments section somehow here, feedback is welcome via Twitter :)