Scala Test-Driven Development

We start with a very minute subset of the problem in hand. In Agile parlance, this problem is also called a story. We write a test that will fail for lack of proper application code to make it work. Then we fix only enough of the application code to make the test pass. At this point, we need to restrain ourselves from over engineering and write just enough code to make the test pass. Then we write more failing tests and fix code to fix these tests. This iterative process goes on till all the requirements of the story have been fully met.

At this point, we realize that if our solution is incomplete then this would mean that the acceptance criteria of the story is incomplete. So instead of assuming what should have been, we ask questions to the customer. This leads to better communication between the customer/analyst and programmers. Historically, programmers have worked in a dark dingy room on a set of requirements that they hardly had any input into. Communication between the programmer and the end customer is very important for the success of any project. More often than not, I have seen customers realize the limitations of their ideas once more questions are asked. They also feel more involved in day-to-day progress rather than just getting to see the final product.

Scala is a general purpose programming language. Scala is an acronym for Scalable Language. This reflects the vision of its creators of making Scala a language that grows with the programmer's experience of it. The fact that Scala and Java objects can be freely mixed makes transition from Java to Scala quite easy.

Scala is also a full-blown functional language. Unlike in other languages, such as Haskell, which is a pure functional language, Scala allows interoperability with Java and support for object-oriented programming. Scala also allows the use of both pure and impure functions. Impure functions have side effects such as mutation, I/O, and exceptions. The purist approach to Scala programming encourages the use of pure functions only.

Scala is a type-safe JVM language that incorporates both object-oriented and functional programming in an extremely concise, logical, and extraordinarily powerful language.

Here are some advantages of using Scala:

Scala Build Tool (SBT) is a build tool that allows the compiling, running, testing, packaging, and deployment of your code. SBT is mostly used with Scala projects, but it can as easily be used for projects in other languages. In this book, we will be using SBT as a build tool for managing our project and running our tests.

SBT is written in Scala and can use many of the features of the Scala language. Build definitions for SBT are also written in Scala. These definitions are both flexible and powerful. SBT also allows the use of plugins and dependency management. If you have used a build tool such as Maven or Gradle in any of your previous incarnations, you will find SBT a breeze.

The following are the reasons we choose SBT:

Here are a few of the resources for learning Scala:

Here are a few of the resources for learning SBT:

We have done enough jibber-jabber to lay the groundwork for getting our hands on the driving plates now. Let's start with setting up the environment so we can write, compile, and run a test-driven application using Scala and SBT.

This is the barebone setup you need to write in order to create a very trivial project that builds using SBT.

There is a default project directory structure for SBT projects that defines where SBT will look for application code and tests. By default, SBT uses a similar directory structure to Maven:

SBT uses build.sbt as a default build definition file. There are other variations of build definition files, such as .scala and multi-project files. For the scope of this book, we will only look at the build.sbt definition file.

Run these commands on the command line to create the directory structure:

Create a file using any editor with the content given underneath and save it as build.sbt:

name := "HelloWorld" 
version := "1.0" 
 
scalaVersion := "2.11.8" 
 
libraryDependencies += "org.scalatest" %% "scalatest" % "2.2.6" %  "test" 
 
    

How easy would it have been to write just a Scala function that will return Hello World? Then again, where is the fun in that? Since we have made a commitment to learn TDD, let's start with the test:

Hey presto! An error. Well that's what we had expected. Congratulations! This is your first failing test. Now let's fix the test one step at a time.

Looking at the compilation error, we can see that the compiler could not find the Hello.scala class. Let's create a new package com.packt under src/main/scala. Add a class Hello.scala here with this content:

package com.packt 
object Hello { 
 
} 

You may be wondering why we are adding an empty class here. This is because we are doing TDD and just doing enough to make the first error go away. Now we will re-run sbt test and see output similar to this:

[info] Loading project definition from /Packt/HelloWorld/project
[info] Set current project to Chap1 (in build file:/Packt/HelloWorld/)
[info] Compiling 1 Scala source to /Packt/HelloWorld/target/
scala/classes...
[info] Compiling 1 Scala source to /Packt/HelloWorld/target/scala/test- 
classes...
[error] /Packt/Chap1/src/test/scala-2.11/com/packt/HelloTest.scala:7:
value displaySalutation is not a member of object com.packt.Hello
[error]     assert(Hello.displaySalutation == "Hello World")
[error]                  ^
[error] one error found
[error] (test:compileIncremental) Compilation failed

Again we get an error, but this time it is complaining about a missing member, displaySalutation. At this point, we can make changes to the class Hello and introduce a member function, displaySalutation. It will look like this:

package com.packt 
 
object Hello { 
  def displaySalutation = "" 
} 

Now re-run sbt test. This time the output should look similar to this:

$ sbt test                                                                                                                                  
[info] Loading project definition from /Packt/HelloWorld/project
[info] Set current project to Chap1
(in build file:/Packt/ HelloWorld /)
[info] Compiling 1 Scala source to /Packt/ HelloWorld 
/target/scala/classes...
[info] HelloTests:
[info] - displaySalutation returns 'Hello World' *** FAILED ***
[info]   "[]" did not equal "[Hello World]" (HelloTest.scala:7)
[info] Run completed in 227 milliseconds.
[info] Total number of tests run: 1
[info] Suites: completed 1, aborted 0
[info] Tests: succeeded 0, failed 1, canceled 0, ignored 0, pending 0
[info] *** 1 TEST FAILED ***
[error] Failed tests:
[error] com.packt.HelloTests
[error] (test:test) sbt.TestsFailedException: Tests unsuccessful

The output is better this time as there are no compilation problems. The build fails because of the failure of the test. Our test makes an assertion that the output of displaySalutation should be Hello World, and our current implementation of Hello.scala (deliberately) returns an empty string. At this point, we can change the empty string to "Hello World" so the content of Hello.scala looks like this:

package com.packt 
object Hello { 
  def displaySalutation = "Hello World" 
} 

Let us re-run the task sbt test. This time we will get the expected output:

$ sbt test
[info] Loading project definition from /Packt/HelloWorld/project
[info] Updating {file:/Packt/HelloWorld/project/}helloworld-build...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Set current project to HelloWorld
(in build file:/Packt/HelloWorld/)
[info] Updating {file:/Packt/HelloWorld/}helloworld...
[info] Resolving jline#jline;2.12.1 ...
[info] Done updating.
[info] Compiling 1 Scala source to
/Packt/HelloWorld/target/scala/classes...
[info] Compiling 1 Scala source to /Packt/HelloWorld/target/scala/test-
classes...
[info] HelloTests:
[info] - the name is set correctly in constructor
[info] Run completed in 327 milliseconds.
[info] Total number of tests run: 1
[info] Suites: completed 1, aborted 0
[info] Tests: succeeded 1, failed 0, canceled 0, ignored 0, pending 0
[info] All tests passed.

This leads us to a solution that is fully test-driven. We can argue about the notion of too much testing and the triviality of the tests, but let's hold off till later chapters. For now, just bask in the glory of having written your first Scala TDD application.