Tuesday, October 25, 2016

Simplifying Validations Using the Strategy(Enum) Pattern

In one of my previous projects we had to perform series of complex validations to prepare some input data. Below will explain the scenario.
  • Call a service and perform some complex validations based on this service response to prepare one of the input values for using it in another service call. 
  • You may need to check for multiple inputs with separate complex logic, but at the end you would select only a particular input for another service call.
  • You decide the number of inputs. The validation will be performed for all these inputs. You may add or remove number of inputs at any point of time so, we need a flexible way to specify that.
Generally, we use multiple if...else blocks, but, it would lead to readability, maintainability issues. Hence, we came up with an approach of using strategy pattern via Enum. 

The approach is explained with working sample code and posted in DZone site. Hope this will be useful.





Sunday, October 9, 2016

Need of 'describe()' level hook methods in Mocha

Introduction

Mocha is a javascript based testing framework for NodeJS. When we were working on the automation testing for the NodeJS application we used data driven based approach for running the test cases against multiple test data. We came across a situation where we had to prepare array of test data dynamically for using it with data driven approach for different test cases. But, we got stuck there due to nature of hook method execution. We will discuss it in details in this post.

The Background

An introduction to Mocha

I think it would be better to tell you shortly and quickly about Mocha in case you are not familiar with this or you need little brush up.

As mentioned earlier in this post, Mocha is a Javascript based testing framework for NodeJS applications. The way it works is, it has a block called 'describe()' which is nothing but your test suite. You can have nested 'describe()'. Within this block you can have normally 'it()' block which is nothing but your test case. 

You may want to initialize or prepare something before your 'it()' block ie., before your test case execution starts. Similarly, you may also want to cleanup something after the execution of the test case. For this purpose Mocha provides you hook methods 'before(), beforeEach(), after() and afterEach()'. 

As their name states, beforeEach() and afterEach() hook methods will be executed before and after each test case within a suite. The before() will be executed before running any of the test case and similarly after() will be executed after running all the test cases within a suite.

Using data-driven module

When you want to run the same test case for multiple times with different set of data you may need the data-driven module. When you use this module you need to pass two parameters, the array of test data and then a callback function. 

We used this approach as we wanted to run against set of test data. But, we had a requirement to prepare the array of test data dynamically by fetching data from a DB. There we got stuck as we couldn't find a way to set this dynamic value for the data-driven module. The reason is that the data-driven module is executed before the 'it()' block and hence the hook methods won't help.

The hook methods are always the 'it()' block specific or in other words it is test case specific. But, we wanted the hook methods in the 'describe()' level or in the test suite level.

The below example will explain this scenario.
var testData = [{country: 'NIL'}],
dataDriven = require('data-driven'),
assert = require('assert');

describe('@Testing_For_Describe_Level_Hook_Method_To_Update_TestData@', function () {

    describe('@Updated testData for US@', function () {
        before(function (done) {
            testData = [{country: 'US'}];
            done();
        });
        dataDriven(testData, function () {
            it('expecting updated testData for US', function (ctx, done) {
                assert.equal(ctx.country, 'US');
                done();
            });
        });
    });

    describe('@Updated testData for UK@', function () {
        before(function (done) {
            testData = [{country: 'UK'}];
            done();
        });
        dataDriven(testData, function () {
            it('expecting updated testData for UK', function (ctx, done) {
                assert.equal(ctx.country, 'UK');
                done();
            });
        });
    });
});
Here, the test suite will fail. We update the testData within 'before()' hook method which will be called just before the 'it()' block. But, we use the testData variable within dataDriven() which will be executed before executing the 'it()' block.
So, what we need here is a place to update the variable before the 'it()' block execution begins. May be we need the before() hook method execution just before the 'describe' block ('describe()' level hook method).

The Solution we followed

We tried updating the test data variable above the dataDriven() and somewhere within the 'describe()', but nothing worked out due to asynchronous behavior. Hence, we finally maintained a separate variable for each country, set in the beginning and used it in data-driven module as below.
var testData_US =[{country: 'US'}];
var testData_UK =[{country: 'UK'}];
dataDriven(testData_US, function () { }
dataDriven(testData_UK, function () {}
It worked! but, the pain in our case was to prepare the test data well in advance and store it in a file and then referencing it here through these variables as given below.
var testData_US = require('../../../testData_US.json');
var testData_UK =require('../../../testData_UK.json');
dataDriven(testData_US, function () { }
dataDriven(testData_UK, function () {}

Conclusion

Though we got a working solution now, we feel that it is just a temporary workaround. Hence, I requested the Mocha team for helping us having a describe() level hook methods. Here is the request and waiting for the response. Hopefully there will be a better way to set the dynamic data. You are welcome if you know some better approach to resolve this!

Wednesday, October 5, 2016

Java 8 Lambda Expressions - How does it work?

Introduction

You might wonder how the Lambda expression works in Java 8. What happens during the compile time? How does the compiler handle this? And also, how does the JVM able to run the method at run time. The only answer to these questions is just to follow this post. 

In this post we will discuss about the internal working of Lambda expression.

What does the Compiler do?

Sugaring and De-sugaring

I would like to recall what is sugaring here. Sugaring means make something sweet by keeping it simple, more clear and concise. When we apply sugaring to our code we get simple expression like Lambda expression. Hence, Lambda expression is a sugared code.

When you have Lambda expression in your code the compiler feels the sweet in that and it knows the JVM don't like this. Hence, it de-sugars that code. In other words it makes that anonymous method verbose as below. For our discussion take the example of creating a thread using Runnable functional interface.
compiler de-sugar the code
De-sugaring
As usual the compiler prepares the byte code instructions, but this time it adds special instruction for evaluating the Lambda expression. It adds invokeDynamic byte code instruction which has details of the target functional interface like its type(Runnable in our case), its method name(run() in our case), its parameters(no parameters in our case) and return type (void in our case).
Bytecode instructions

How does the JVM handles the byte code instructions?

Linkage

Once the invokedynamic instruction is encountered the JVM makes the call to the factory called LambdaMetaFactory. This factory has few bootstrap methods for serving the JVM request. The factory uses the given byte code instructions to create an implementation class(the name takes the format of 'X$$Lambda$1') which would implement the target functional interface(Runnable).

If there is no parameters in the target functional interface method then the LambdaMetaFactory creates an instance of the implementation class (called as Function Object) and attaches a MethodHandle to it. Now, the meta factory creates and returns the LambdaFactory (called as CallSite) with the attached method handle.

If there are some target method parameters then the lambda meta factory generates and attaches  the MethodHandle to the implementation class's constructor. In this case the LambdaFactory(CallSite) takes care of creating the Function object and attaching MethodHandle to it. 

In short, when the JVM invokes the invoke dynamic instruction it calls the LambdaMetaFactory which creates and returns the LambdaFactory(CallSite) with the MethodHandle to the target type implementation class. This entire process is called Linkage. Now, the method handle which is the target field of the CallSite will be retuned to the JVM.

This linkage process happens only for the first time for the given target type functional interface. The further execution on the same target type functional interface will happen through the     LambdaFactory (CallSite) directly. The call on the CallSite's target will return the existing function object.

Capture

The JVM now invokes the CallSite's target(MethodHandle) and the corresponding function object is returned. This process is called Capture.

Invocation

Once the function object is returned a call to the implementation method(de-sugared code) happens and the code is executed. This is process is called Invocation.

The above process is explained in the below figure.
Evaluation of Lambda Expression

Conclusion

If you have already gone through 'Java 8 Lambda Expressions - The What and Why' post you could recollect the example we discussed on the AWT event handling where the instance of type ActionListener will be registered to the event source for notification. Similarly, here the function object is registered with the Thread for notification. Hope you enjoyed reading the post!


Tuesday, October 4, 2016

Java 8 Lambda Expressions - The working code example

Introduction

In the previous post we had discussed about the Why and What of Lambda expressions. In this post we will take an working example to understand Lambda expressions better. It will be a step by step interactive discussion. We will start with having our own custom implementation and then will be replacing with Java 8 functional interfaces. You can access, download and run all these examples from this git repo.  Java 8 Lambda Expressions - Examples. The package java8.account  is the one we will be discussing here. Just use mvn test to run all the examples. Lets begin!

Example Application Structure

The example application is all about creating different types of Bank accounts and searching the accounts based on different criteria. The classes, interfaces and the relationship between them are given in the below figures.

Application Structure having Account class inherited by Savings and Checking Account classes
Application Structure - Classes
Here, the Account, an abstract class is inherited by two different types of account called as SavingsAccount and CheckingAccount. Gender is an Enum type.
Application Structure - Utility & Interfaces
Here, we have an utility class, BankUtil which uses all the interfaces, TestAccount, PrintAccount and FetchAccountInfo. We will discuss about the usage of these interfaces later part in this post.

Searching Accounts

The main discussion here is how can we have better search method for a list of accounts in an easiest and efficient way. Lets assume that we have a method to create and return list of accounts in the BankUtil as below.
public static List getAccounts() {
          List accounts = Arrays.asList (
                               new SavingsAccount("A", 2000, 500, Gender.FEMALE),
                               new CheckingAccount("B", 4000, 5000, Gender.MALE),
                               new SavingsAccount("C", 3000, 500, Gender.MALE),
                               new CheckingAccount("D", 5000, 5000, Gender.FEMALE));
          return accounts;
}
The constructor parameters are accountName, balance, minimumBalance(in case of SA), creditLimit(in case of CA) and Gender. This can be represented as below for easy understanding.
Representation of List of Accounts
Now, as we have a list of accounts, we want to search these based on some criteria say, the available balance in an account. The normal way we search the list of accounts is just by using the forEach loop as given below.
//simple search criteria
public static List searchAccounts(List accounts, double balance){
       List searchedAccounts = new ArrayList();
       for(Account a : accounts) {
             if(a.getBalance() >= balance) {
                     searchedAccounts.add(a);
                     System.out.println(a);
             }
       }
       return searchedAccounts;
}
Here, we search the accounts based on the available balance and then returns the searched accounts. And, we can call this method as below.
public static void main(String args[]) {
         List accounts = BankUtil.getAccounts();
         BankUtil.searchAccounts(accounts, 1000);
}
This looks fine for simple search with balance, but what if we wanted to search the accounts within some balance range? We may need to modify our search method as below.
public static void searchAccounts(List accounts, double minBal, double maxBal) { }
Change is the only constant thing. Hence, we may change our requirement at anytime and want to search based on different different criteria. Every time we change our criteria we need to update our search method. Yes, we see a maintainability issue here. 

Hence, the generic solution would be moving the test logic out of our main code and the new definition will be as below.
//with custom Functional interface
public static List searchAccounts(List accounts, TestAccount tester) {
            List searchedAccounts = new ArrayList();
            for (Account a : accounts) {
                 if (tester.test(a)) {
                       searchedAccounts.add(a);
                       System.out.println(a);
                  }
           }
           return searchedAccounts;
}
Ok, this looks great now. How about the caller? The caller should pass two parameters to this search method, List of accounts and the instance of TestAccount. As we are familiar with Lambda expressions no need to use any Inner class or Anonymous Inner class for the purpose of passing the TestAccount instance. We can use Lambda expression here and it would look like as below.
//using Lambda
List accounts = BankUtil.getAccounts();
BankUtil.searchAccounts (accounts,
                                           a -> a.getBalance() >= 2000 && a.getBalance() <= 5000);
I think we are good now. But, still we can improve the above search method by moving the line which prints the value of account to an interface so that the searched data can be consumed and utilized for different purpose other than just printing the value.

To do the same we can create another interface called PrintAccount which will have a method to accept a parameter and do something on that.

Hence, the search method will be as below now.
//with custom Functional interface
public static List searchAccounts(List accounts, TestAccount tester, PrintAccount  consumer) {
            List searchedAccounts = new ArrayList();
            for (Account a : accounts) {
                 if (tester.test(a)) {
                       searchedAccounts.add(a);
                       consumer.accept(a);
                  }
           }
           return searchedAccounts;
}
and the method call will be
//using Lambda
List accounts = BankUtil.getAccounts();
BankUtil.searchAccounts (accounts,
                    a -> a.getBalance() >= 2000 && a.getBalance() <= 5000,
                    a -> System.out.println(a) );
Cool. We are moving fast on Lambda expressions and have used it properly. But, still there is a room for improvement. Lets go back to the search method again. What we do here is that we retrieve the account based on some balance, we print the entire account details and then we return the list of searched accounts for further use.

What if we wanted to access specific details from Account and manipulate that? For example, I may want to retrieve the account name of each account and to display it in upper case? How can I do that here?

Yes, you were right. We need to create an interface and keep that logic there. Lets define another interface called FetchAccountInfo which will have method to accept account and apply our logic into the details.

Now, our latest search method will be
//with custom Functional interface
public static List searchAccounts(List accounts, TestAccount tester, FetchAccountInfo mapper, PrintAccount consumer) {
      List searchedAccounts = new ArrayList();
      for (Account a : accounts) {
            if (tester.test(a)) {
                   searchedAccounts.add(a);
                   String data = mapper.apply(a);
                   consumer.accept(data);
            }
      }
      return searchedAccounts;
}
and similarly our method call will be updated as below.
//using Lambda
List accounts = BankUtil.getAccounts();
BankUtil.searchAccounts (accounts,
                   a -> a.getBalance() >= 2000 && a.getBalance() <= 5000,
                   a->a.getAccountName(),
                   accName -> System.out.println(accName) );
Excellent! we are done with our example discussion to understand the use of Lambda Expressions better. One thing we noticed here is that the method call would become so simple with the help of Lambda expressions. No more Anonymous classes! 

But, did you notice use of interfaces? They are functional interfaces(have only one abstract method) which is what required for Lambda usage. Whenever we wanted more customization and flexibility we continue creating the functional interfaces. This might be repeated for multiple projects. How to avoid these creation of interfaces? Java 8 helps here. It gives you the package java.util.function with many functional  interfaces for different purposes. Java 8 - Functional Interfaces.

I would recommend you to go thro' this package. When you visit this page you might wonder that we have already used some those interfaces. Yes, you are right. You will be able to map our interfaces to those as below.
TestAccount          -->   Predicate
FetchAccountInfo -->   Function
PrintAccount         -->   Consumer
Hence, we may replace our interface usage with these Java 8 Functional interfaces. So, before start creating your own functional interface, please check this package.

The replaced code will be as below
//with custom Functional interface
public static List searchAccounts(List accounts, Predicate tester, Function mapper, Consumer consumer) {
      List searchedAccounts = new ArrayList();
      for (Account a : accounts) {
            if (tester.test(a)) {
                   searchedAccounts.add(a);
                   String data = mapper.apply(a);
                   consumer.accept(data);
            }
      }
      return searchedAccounts;
}
Hmmm...lot of code! I can hear your mind. As we mentioned already there is always a room for improvement and Java 8 helps in that.

The above all can be replaced by Java 8 Streams aggregate methods. We can discuss about Streams in another post. But, for now just we can have the equivalent code.
public static List searchUsingStreams() {
     //using aggregate functions without referencing/using any functional interface directly
     List searchedAccountNames = new ArrayList();
     BankUtil.getAccounts().stream()
                                            .filter(a -> a.getBalance() >= 2000 && a.getBalance() <=
                                                              5000 && a.getGender() == Gender.MALE)
                                            .map(a -> a.getAccountName())
                                            .forEach(accName -> { System.out.println(accName);


      searchedAccountNames.add(accName);});
      return searchedAccountNames;
}
This is simple, declarative and performance oriented. You can exactly match with our previous search method implementation.  If you look at the parameter type of filter() which is Predicate, the parameter type of map() is of type Function and finally the parameter of forEach() is of Consumer type. This is the power of Streams!

Want to Practice?

Practice makes us perfect. So, to conclude our understanding of Lambda expressions lets take one simple exercise. 

Create a simple calculator application which should accept three parameters. The first two parameters are integers, which need to be computed and the third parameter is the operation type.  Use lambda expressions to call/use this calculator for different types of operation such as addition, subtraction, division and multiplication.

You can refer the git repo Java 8 Lambda Examples package java8.calculator from src/main/java and src/test/java for the solution.

Conclusion

I hope you were able to understand the usage of Lambda expressions better. Will connect later on next post. Bye for now!

Sunday, October 2, 2016

Java 8 Lambda Expressions - The What and Why

Introduction

Java 8 has lot of new interesting features. Lambda expression is one of them. This feature is not something very new. Microsoft DotNet already had this feature in v3.0. Dynamic languages like Javascript, Scala, Ruby are all already having this feature. We could say Lambda expressions are simplified form of anonymous methods.

In this post I would like to discuss about what is Lambda expression, why do we need this.

Why do we need Lambda Expression in Java?

Why are we interested in this feature after so long time? Lets take below example for our discussion. When we create GUI in Java using AWT package we deal with three main components, Event Source, Event and Event Handler.

AWT Event Handling Components, Event Source, Event and Event Handler
Java AWT Event Handling

In the above GUI we have a simple button 'OK' as 'Event Source'. Whenever we perform some action on the event source we actually generate 'Event' and it is passed to another component called 'Event Handler'. 

The Event Handler is the important component for our discussion. It is a set of instruction/behavior we want to run at the time of receiving an event. In other words event handler is a set of code we want to run at a later point of time in response to an event.

It looks straightforward and simple, but in Java we can't pass set of code instructions directly to another part of the program for later execution. In our example we can't directly associate the event handler code to the event source for later execution whenever there is an event generated from the event source. 

How we handle this in Java is explained in the below image.


Java way of associating code for later execution in Object oriented way
Java way of associating code for later execution

As Java is Object oriented language, we handle everything in terms of objects. Hence, we wrap this event handler code into a method (public void actionPerformed(ActionEvent e){ }), then add this method to an Object (ActionListener type) and then add/register this Object to the event source for later execution. 

Now, when an event is generated from the Event Source the registered EventListener object is notified and it executes the associated method(s).

We write the below code in Java to do the same above.

Associating the Event Handler to the Event Source using btn.addActionListener()
Associating the Event Handler to the Event Source in Java

Here,
  • We create an instance of type ActionListener interface which has one abstract method (event handler method) called
 public void actionPerformed(ActionEvent e)
  • Register this instance to the Event Source ('OK' button) by using the code
btnOk.addActionListener(instance of ActionListener)
The important point to note here is the way we create instance of ActionListener interface. There is no class implementing ActionListener interface. We just use Anonymous Inner class. This Anonymous inner class helps avoid creating separate implementation classes and saves coding time.

But, there are few concerns with the usage of Anonymous Inner classes. We can consider two of them.
  1. At run time a separate instance is created for each Anonymous inner class definition. Even if the same definition is repeated multiple times the run time creates multiple instances for each anonymous inner class definition. This wastes the memory as well as adds overhead to the garbage collection process.
  2. If you have another Event Source and want to handle events for that source then you may need to add one more set of similar code as above. This leads to have more boiler plate code as mentioned in the below image.

Redundant Event Handler code. new ActionListner() { public void actionPerformed(){}}
Boiler plate Event Handler code

So, what we are going to do here is to just remove these boiler plate code and you will get the below as remaining.

Anonymous Method, without method name-just has param and body
Anonymous Method

Here, we just kept the method parameter(s) and the method body. Such type of structure is called as Anonymous Method. We have removed the instance type as well as method name. 

In other words we leave/register the anonymous method to the event source for later execution. Please recollect what we had mentioned in the beginning that we had registered anonymous class to the event source. 

Fine, now when an event is generated the Event object will be assigned to the param 'e'  and will be passed to the method body. The method body now will be executed and will return the result. You can now understand the usage of the arrow which takes the parameter(s) and passing to the method body.

The working example code is available in Java 8 Lambda Examples. Please run TestLambda.java.

What is Lambda Expression in Java?

So, we moved from anonymous class to anonymous method in Java 8. We can take another example of creating a thread using Runnable interface. We can follow the same here and is explained in the below image.

Java 8 helps replacing anonymous class with anonymous method
Moving from Anonymous Class to Method

The anonymous method is nothing but the simple expression as discussed above.
(ActionEvent e) --> { ----};
() --> System.out.println("Inner Thread"); 
These expressions are called as Lambda Expressions in Java.

The first expression can be rewritten without specifying the parameter type as below.
e --> { System.out.println("button is clicked!")}; (parentheses can be removed as there is only one param)
e --> System.out.println("button is clicked!"); (the curly braces can be removed as there is only one statement within the body) 
Similarly if there is another event source btnCancel then we can write the expression as below.
e --> System.out.println("button is clicked!")
The lambda expression can be assigned to a variable for later reuse and using it in a declarative way.

ActionListener btnListener = e -> System.out.println(“button is clicked!”);
btnOk.addActionListener(btnListener);
btnCancel.addActionListener(btnListener);

The important point to note here is that Lambda Expression works only with an Interface with only one abstract method. Such type of interface is called a Functional interface in Java 8. Hence, ActionListener and Runnable interfaces which we discussed are functional interfaces. There are many functional interfaces added in Java 8 in the package java.util.function. You can spend some time going thro' this package and get familiar with all the new functional interfaces and their methods.

Summary

Based on the above discussion we can understand the need of Lambda Expression in Java as below.

summary-why do we need lambda
Summary

Hope you enjoyed the post. Welcome your comments!


Do you know - Series - 4: Boxing and Unboxing - Integer assignment and comparison

We know about boxing and unboxing in Java. It is about automatic conversion of primitive type value into its Wrapper Object equivalent type...