Browsing: / Home
Shortlink

TDD TDD TDD …

By Prabhu Sunderaraman on September 16, 2015 in

In the last few months, I have been extremely busy working for a client(still working) developing a suite of applications. Quite naturally, TDD(Test Driven Development) is the standard choice. Writing unit-tests, seeing them fail, filling in code, seeing the green bar, mocking several objects, verifying the behaviors etc., have been such a fascinating experience.

As a welcome coincidence, I had to go to Hyderabad for a three day training on TDD. I had a group of fifteen experienced developers, trying hard to adapt to this style.

IMG_20150914_141853549_HDR

Developers working in pairs

We had lots of discussions, lots of questions about practical difficulties in following it in their company, managerial issues and so on. Like any other sessions on TDD, there were thoroughly-convinced, convinced-with-doubts-yet, skeptical and outrightly-rejected participants. As usual, the thoroughly-convinced were the ones in the lesser age group. It confirms my theory that developers need to be introduced to TDD(or anything good!!!) much earlier in their career.

To the doubtful souls, I always share Dr.Laurie William‘s research on TDD vs. Non-TDD that you can find here. Here’re some highlights on some of the results on making two sets of programmers develop using TDD and Non-TDD.

  • The TDD developers took more time to develop the application, contrary to the research hypothesis.
  • The possible reasons for TDD developers to take more time could include the fact that TDD developers developed test case along with code while non-TDD developers developed only the code.
  • Further, the non-TDD developers failed to develop code according to the requirement specification resulting in faster implementation.
  • The non-TDD developers were asked to write test cases after code development, however they failed to write any test cases.
  • Only one pair wrote any worthwhile test cases.
  • These test cases could not be evaluated due to lack of sufficient other data points.

The code of the professional programmers was evaluated using 20 black box test cases. The test cases validated the robustness of the code, such as error handling capabilities and degree to which requirement specifications were incorporated (An application that passes 15 or more test cases can be thought of as a robust application)

  • 80% of the TDD pairs’ code passed majority of the test cases (passing 16 to 20 test cases)
  • Only 50% of the non-TDD pairs managed to achieve the same
Mixx Delicious Digg Facebook Twitter
Shortlink

Syntactic sugar in Scala – III

By Prabhu Sunderaraman on August 27, 2015 in

Like implicit variables, implicit methods offer a great deal of flexibility in Scala. They help us in wrapping up objects. However, it can make us very tired, if overused. Here’s an example of using implicit methods.

Let me implement one of my favorite Groovy examples from the book, Programming Groovy (Venkat Subramaniam) using implicit methods in Scala. 

def main(args:Array[String]):Unit = {
   println(5 daysFromNow)
}

5 daysFromNow is self-explanatory. But compiler will give you an error, saying daysFromNow is not a member of Int. So let’s get into action. We need to tell the compiler that Int will be implicitly converted to an Object that has daysFromNow behavior. Let’s do that. 

implicit def hereWeGo(x:Int) = {
   new CalendarUtil(5)
}

The hereWeGo() method is defined as implicit. It takes in an integer and returns an instance of CalendarUtil as shown above. So here is the class CalendarUtil. 

class CalendarUtil(count:Int){
	def daysFromNow() = {
	   import java.util.{Date,Calendar}
	   val cldr = Calendar.getInstance
	   cldr.setTime(new Date())
	   cldr.add(Calendar.DATE,count)
	   cldr.getTime()
	}
}

And that’s the power of implicit methods.

Mixx Delicious Digg Facebook Twitter
Shortlink

Syntactic Sugar in Scala – Part II

By Prabhu Sunderaraman on August 12, 2015 in

In my first consulting assignment in Scala, the most frustrating piece of code was the one involving implicit keyword. There was a portion of code written by the client and the team was huffing and puffing trying to understand the code.

implicit keyword in Scala gives the flexibility of using variables and methods that are implicitly defined. Confusing?. While it’s a good feature if used judiciously, it can become a bane when overused. Let’s take this code as example. 

def add(a:Int)(implicit b:Int) = a+b
add(12)

In the code above, b is defined as an implicit variable. And we invoke the function by passing only one value. What does that mean? The add function looks for another Int that is implicitly defined in the code(!) and uses it. But now that we have not defined it; Scala compiler gives an error stating, could not find implicit value for parameter b: Int. We can make this code work by writing this. 

implicit val x:Int = 14
def add(a:Int)(implicit b:Int) = a+b
add(12)//Prints 26

Since we have defined an implicit integer variable x, compiler automatically picks it up and passes it as the second argument of add function.

So what happens if we have more than one implicit variable? You can try that out and see :)

Mixx Delicious Digg Facebook Twitter
Shortlink

Java collections – blast from the past

By Prabhu Sunderaraman on July 30, 2015 in

I got a chance to discuss our very old Java collections with a group of guys today. We went through various collections and tried to play with them. It was exciting and brought back memories of my Java days. I thought I would just list down some beaten-to-death points about the these collections we discussed today.

  • ArrayList allows duplication
  • ArrayList retains the insertion order
  • ArrayList is slower in terms add/remove compared to LinkedList
  • Set does not allow duplication;
  • But checks if the item is duplicate using the hashCode and equals method of the item
  • HashSet sorts based on mod(16) ie., the initial capacity
  • TreeSet is a sorted collection
  • Each item should implement Comparable interface for the sorting order.
  • HashMap does not allow duplication
  • No guarantee on sorting/ordering of the keys;depends on the mod(capacity)
  • Hashtable and HashMap are very similar, one of them is synchronized and other than is not synchronized
  • LinkedHashMap does not allow duplication
  • Maintains the insertion order
  • No sorting
  • TreeMap does not allow duplication
  • Sorts the keys
  • Need to implement Comparable interface for specifying the sorting algorithm
  • Runtime Exception if the item does not implement Comparable interface

:) :) :)

Mixx Delicious Digg Facebook Twitter
Shortlink

Syntactic sugar in Scala – I

By Prabhu Sunderaraman on July 21, 2015 in

Scala has concise syntax. Period. This is a huge plus point because of brevity and expressiveness in code and a minus point because it’s not too easy to the naked eyes. Let’s discuss the syntactic sugar in use of methods in this post.
Say you have a Calculator class with add() method as shown here. 

class Calculator {
 def add(num1:Int,num2:Int):Int = {
 	num1 + num2
 }
}

The add() method accepts two arguments and returns their sum. In Scala, we know that the last line of a method is taken as a return value, so return keyword is omitted. We can write the add() method like this as well. You can get rid of the curly braces completely. 

class Calculator {
 def add(num1:Int,num2:Int):Int = num1 + num2
}

We can write a method and ignore the return type too like this. 

class Calculator {
 def add(num1:Int,num2:Int) = num1 + num2
}

For the naked eyes, it may hurt initially, but it’s pretty easy when you get used to it.

Mixx Delicious Digg Facebook Twitter