The preceding diagram is the typical directory structure of a Scala project. If you are familiar with the Java tools ecosystem, then you will notice the similarities between the maven project layout.

In src, we can see project sources ( main and test). target is a place where output artifacts are created, whereas project is used as a place to internally build the project. We will cover all of these concepts later on.

organization := "com.packt.courseware"name := "chatbot1"version := "0.1-SNAPSHOT"
scalaVersion := "2.12.4"

The head of any project is its build.sbt file. It consists of the following code:

The text inside it is a plain Scala snippet.

organization, name, and version are instances of sbt.key. For this point of view, := is a binary operator defined on keys. In Scala, any method with two arguments can be used with the syntax of a binary operator. := is a valid method name.

build.sbt is interpreted by the sbt tool.

We will now talk about the basic sbt commands.

sbt compile should compile the project and live somewhere in its target compiled Java classes.

sbt run executes the main function of the project. Therefore, we can try to interact with our chatbot:

rssh3:1-project rssh$ sbt run
[info] Loading global plugins from /Users/rssh/.sbt/0.13/plugins
[info] Set current project to chatbot1 (in build file:/Users/rssh/work/packt/professional-scala/Lesson 1/1-project/)
[info] Running com.packt.courseware.Chatbot1
Hi! What is your name? Jon
  Jon, tell me something interesting, say 'bye' to end the talk

>qqq
interesting..
>ddd
interesting...
>bye
ok, bye
 [success] Total time: 19 s, completed Dec 1, 2017 7:18:42 AM

The output of the code is as follows:

sbt package prepares an output artifact. After running it, it will create file called target/chatbot1_2.12-0.1-SNAPSHOT.jar.

chatbot1 is the name of our project; 0.1-SNAPSHOT – version. 2.12 is the version of the Scala compiler.

Scala guarantees binary compatibility only within the scope of a minor version. If, for some reason, the project still uses scala-2.11, then it must use the library, which was created for scala-2.11. On the other hand, updating to the next compiler version can be a long process for projects with many dependencies. To allow the same library to exist in the repository with different scalaVersions, we need to have an appropriate suffix in the jar file.

sbt publish-local – publishes the artifact on to your local repository.

Now let's see our sample project and sbt tool.

Another part of the developer toolbox is an IDE tool (Integrated Development Environment). For our book, we will use Intellij IDEA community edition with the Scala plugin. This is not the only option: other alternatives are scala-ide, based on IBM Eclipse and Ensime (http://ensime.github.io/), which brings IDE features to any programmable text editors, from vi to emacs.

All tools support importing the project layout from build.sbt.

For running our project from the IDE, we should edit the project's configuration (Menu: Build/ Edit configuration or Run/ Edit configuration, depending on which version of IDEA you are using).

Running the Project from IDE:

Another tool that we will frequently use is REPL (Read Eval Print Loop). It is often used for quickly evaluating Scala expressions.

From sbt, we can enter REPL mode with the help of the sbt console command. Let's try some simple expressions.

Now, we'll look at how to evaluate expressions. Follow these steps to do so:

Please note that we can have an interactive Scala playboard inside IDE by creating a special file type: a Scala Worksheet. It's useful, but is mainly for demonstration purposes.

For now, let's return to our task: modifying the chatbot program so that it replies with the current time, as requested by the use of time. Let's learn how to do this:

Steps for C ompletion

The main method will look like this:

def main(args: Array[String]): Unit = {
val name = StdIn.readLine("Hi! What is your name?")
println(s" $name, tell me something interesting, say 'bay' to end the talk")
var timeToBye = false
while (!timeToBye)timeToBye = StdIn.readLine(">") 
match {case "bye" => println("ok, bye")truecase "time" => 
println(s"time is ${java.time.LocalTime.now()}")truecase _ => 
println("interesting...")false}
}

After we prepare and package our artifacts, we need to run them as well.

In this book, we will use the running system from unpackaged sources via sbt (as in the early days of Ruby applications), assuming that sources and sbt tools are accessible from the production environment. Using this, we can use build tool commands for sources such as sbt run. In real life, packaging for production is a bit more complex.

Popular methods for doing this are as follows:

Scala compilation unit – This is a set of definitions inside an entity (template-entity), which can be an object, a class, or a trait. We will speak about the Object-Oriented part of the Scala language in detail later. Now, let's look at the basic syntax. Let's define some classes in REPL:

> class X {  def f():Int = 1 }
> Class X defined  // answer in REPL

Definitions inside the entity can be nested entities, functions, or values:

> def f():Int = 1

Here, the function f is defined, returning 1. We will talk about this function in detail in Chapter 3, Functions. Now, let's stay on the top-level view:

> val x = 1

Here, the value x is defined with value 1:

> var y = 2

Here, the mutable variable y is defined with value 2.

Other high-level entities include objects and traits. We can create objects by writing object or trait definitions:

>  object O {  def f():Int =1  }
>  trait O {  def f():Int =1  }


We will talk about classes, objects, and traits in the next chapter.

Now, let's look at defining an object in REPL with the name ZeroPoint.

Steps for Completion:

Scala is an expression-based language, which means that everything is an expression (in the right-hand side of function and value/variable definitions).

Some of the base expressions are:

The preceding syntax will have the same output as { A; B }.

Shortcuts for height-order functions will be described in detail in, Chapter 4, Scala Collections.

We'll look at defining a main function which prints something onscreen and calls the main function.

The full method should look something like this:

  object Chatbot1 {def printHello():Unit = {
println("Hello")}def main(args: Array[String]): Unit = {
printHello() … // unchanged code here
     }
}

Let's add tests to our small program. We'll import <for-students/lesson1/2-project> in our IDE.

This is the directory schema of a Scala project. For adding tests, we should do the following:

For adding dependency, let's add the following line to our build.sbt:

libraryDependencies += "org.scalatest" %% "scalatest" % "3.0.4" % "test"

It's an expression in Scala DSL (domain-specific language), which means that we should add scalatest to our set of library dependencies. Operators %% and % are used for forming the name and classifier for published artifacts. You can refer to the sb t documentation for more detail: http://www.scala-sbt.org/1.x/docs/Library-Dependencies.html.

Before compilation, sbt will download scalatest from a publicly available repository (Maven central), and when running tests, it will add scalatest to the classpath.

We will now run sbt tests from the command line.

We will now see how to run sbt tests from IDEA IDE.

We'll now run sbt Tests from IDEA IDE.

Now let's look at a simple test:

package com.packt.courseware.l1
import org.scalatest.FunSuite

class ExampleSpec extends FunSuite {

  test("example test  should pass") {
     assert(1==1)
  }

}

Here, we define a class which is inherited from scalatest FunSuite.

The test expression is called. When the FunSuite class is initialized and added to a set of tests, the test with name example test should pass and assert an expression as an argument. For now, this looks like magic, but we will show you how to build such DSLs in the next chapter.

Let's run our test with the help of sbt:

sbt test

This command will run all tests and evaluate the test expression.

Now, we'll add another test.

Remember that, when writing chatbot, we want to test one functionality. Our original program only has one function ( main), which contains all of the logic and can't be split into testable parts.

Let's look at Version 2.

package com.packt.courseware.l1

import java.time.LocalTime
import java.time.format.DateTimeFormatter
import scala.io.StdIn

case class LineProcessResult(answer:String,timeToBye:Boolean)

object Chatbot2 {

  def main(args: Array[String]): Unit = {
    val name = StdIn.readLine("Hi! What is your name? ")
    println(s" $name, tell me something interesting, say 'bye' to end the talk")

    var c = LineProcessResult("",false)
    while(!c.timeToBye){
      c = step(StdIn.readLine(">"))
      println(c.answer)
    }

  }

  def step(input:String): LineProcessResult = {
    input match {
      case "bye" => LineProcessResult("ok, bye", true)
      case "time" => LineProcessResult(LocalTime.now().format(DateTimeFormatter.ofPattern("HH:mm:ss")),false)
      case _ => LineProcessResult("interesting...", false)
    }
  }

}

Here, we see some new constructs:

LineProcessingResult is a case class, where the result of processing one of the lines (that is, the chatbot answer and quit flag) is stored.

What is the word case before class?

case classes can participate in pattern matching (while we call one case) and are usually used for data objects. We will look at case classes during the next chapter. It is important to see that an instance of case classes can be created with the LineProcessingResult(x,y) syntax (that is, without new) and an argument to case class constructors ( answers and timeToBye), which automatically become instance variables of the case class.

The functionality of processing one line is encapsulated in the step method, which we can test.

Step receives input from the method argument, not from System.in, therefore making it easier to test. In the case of directly testing the main method, we will need to substitute System.in before test and return one back after the test is finished.

Ok, let's focus on the first test:

package com.packt.courseware.l1

import org.scalatest.FunSuite

class StepTestSpec extends FunSuite {

  test("step of unparded word must be interesting") {
    val r = Chatbot2.step("qqqq")
    assert(! r.timeToBye)
    assert(r.answer == "interesting...")
  }

}

Writing the second test in the same manner will be an easy task. We will look at this in the following exercise.

Now, let's add the second test, which checks bye.

A more complex task would be to write a test for the time query.

Please note that we can't run the test with the concrete time value, but at least we can be sure that the bot answer can't be parsed back to the time form.

So, what can we do to check the line answer and try to transform it back to time? The solution is provided in the following code:

test("local time must be parser") {
val r = Chatbot2.step("time")
val formatter = DateTimeFormatter.ofPattern("HH:mm:ss")
val t = LocalTime.parse(r.answer,formatter)// assertion is not necessary
}

Note that assertion is not necessary. If time does not satisfy the given format, then an exception will be thrown.

It is a good practice to separate functional and effects time for testing. To do this, we will need to substitute the provider of the system time via own.

This will be the first practical task in the next chapter.

Now, let's add the date command to our chatbot program.