bhanunune-blog

[bhanunune-blog]

#2 Test Driven Development Using Scala

This post is continuation to series of posts on TDD using Scala. You can refer the previous post here.

In this post we would be dwelling into the details of available test frameworks in Scala.

Testing Framework

A testing framework is used for the automated testing of software. It is primarily a collection of postulations, perceptions and observations which support automated testing of application code. Its a misconception that testing frameworks are only intended for Unit testing but  however they can be used for Integration, Smoke and Acceptance Testing.

Scala Test and Specs 2 are two main testing frameworks available and in the series of posts, we will be dwelling more into Scala Test Framework.

ScalaTest

Scala Test follows a JUnit style of test case writing which is not very verbose. It provides the flexibility of being able to write tests in various styles. This makes it a comprehensive framework for both BDD and TDD. It also integrates very well with various third party frameworks such as JUnit, TestNG, Ant, Maven and SBT.

Follow the Link if you are not sure on how to create a Scala project with maven dependency management.

Lets look at all scala styles briefly that ScalaTest supports. 

FunSuite

It is good for the transition from xUnit with vivid test names.

import org.scalatest.FunSuite class AddSuite extends FunSuite {      test("3 plus 3 is 6") {           assert((3 + 3) == 6)      }   }

FlatSpec

structure of this style is flat - like xUnit, bu the test name can be written in specification style:

import org.scalatest.FlatSpec   class AddSpec extends FlatSpec {    "Addition of 3 and 3" should "have result 6" in {    assert((3 + 3) == 0)      }   }

FunSpec

This is more analogous to Ruby's RSpec:

import org.scalatest.FunSpec class AddSpec extends FunSpec{      describe("Addition") {          describe("of 3 and 3") {              it("should have result 6") {                  assert((3 + 3) == 6)        }        }    } }

WordSpec

This has similar structure to Specs2:

import org.scalatest.WordSpec   class AddSpec extends WordSpec {  "Addition" when {          "of 3 and 3" should {              "have result 6" in {                  assert((3 + 3) == 6)              }      }  } }

FeatureSpec

It is primarily intended for writing BDD style acceptance tests. This allows for the use of ubiquitous language that can be understood by non-programmers.

import org.scalatest._   class Calculator {      def add(a:Int, b:Int): Int = a + b } class CalcSpec extends FeatureSpec with GivenWhenThen {  info("As a calculator owner")      info("I want to be able add two numbers")      info("so I can get a correct result")      feature("Addition") {    scenario("User adds two numbers") {      Given("a calculator")              val calc = new Calculator      When("two numbers are added")              var result = calc.add(3, 3)      Then("we get correct result")               assert(result == 6)          }  }   }

Next Post

Now that we know all available test frameworks in Scala, in the next post we will look at a problem statement and start writing the code using TDD Approach. Stay Tuned!!!

[bhanunune-blog]

#1 Test Driven Development using Scala

This is first post of the series and it explains the importance of TDD and why development teams should inculcate this methodology to build bug free applications.

TDD:

Test Driven Development is practice of writing your tests before writing any application code. In TDD you will write a test that fails then you will write enough code to make the test pass. This will be an iterative approach

and you keep refactoring the code till all  your tests pass. This is called Red-Green-Refactor-Repeat.

Why TDD?

Code Quality  -    Programmers can be sure of syntactic and semantic correctness of their code.

Evolving Architecture - A purely test driven application code gives way to an evolving architecture. It results in an application that is flexible towards future changes.

Documenting the Code - These tests also document the requirements and application code. Agile purists normally regard comments inside the code as a "smell". According to them your tests should document your code.

Paradigm Shift - TDD forces the programmer to think about testability of the solution before its implementation. To understand how to test a problem would mean a better understanding the problem and understanding its edge cases. This in turn can result in refinement of requirements  discovery of some new requirements.

Maintainable Code - Code becomes more maintainable because any new code insertion will break existing tests if the new code harms existing functionality.

Refactoring Freely – Having a good test coverage over the application code allows the programmer to continuously refactor and improve the code while maintaining an idempotent nature of the application code.

Steps involved in the process of TDD

Iteratively writing failing tests - We start with very minute subset of the problem in hand. In Agile parlance, this problem is also called a story. we write a test that 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. Then we write more failing tests and fix code to fix these tests. This iterative process goes on till the requirements of story full met. At this point, we realize that if our solution is incomplete then this wold mean the acceptance criteria of the story is incomplete. So instead of assuming what should have been, we ask questions to the product owner. This leads to better communication between PO and programmers.

Baby Steps -  Baby steps are key to TDD. Because of this the code may appear incomplete or trivial. But this prevents us from making any major design decisions. When we get closer to the final solution, we will see a natural design pattern evolving.

Next Post:        

We understood the need of TDD in this post. Next post will detail various test frameworks that are available in Scala. We will write a sample code to get an understanding on all the frameworks.              

References:

Image Copyright credits: http://ontheroadtocode.blogspot.com/2015/09/why-do-we-use-red-green-refactoring-and.html

Test Driven Development using Scala