Serialization at Client Side

Serialization is a process of converting Object into Raw data.In javascript many times we need to convert Raw data into Object and viceversa.
For example, when we submit a form, Its data needs to be sent to the server in JSON form.

• Serialization is the process of turning any object into a string.
• De-serialization turns that string back into a native object.

JSON is a lightweight data-interchange format inspired by JavaScript object literal notation.
Certain framework provides method to convert Model, Form data into JSON.
For eg backbone.js provieds following

• Model.toJSON for serialization
• Model.parse for de-serialization

Once we have JSON library we can use the two most useful methods whcih are availble:

• JSON.stringify(obj) — converts an JavaScript object to a JSON string
• JSON.parse(str) — converts a JSON string back to a JavaScript object

 Both are really cool features which we can use where we are interarcting with web services and serer is going to use the object to marshal into a Java Object.

Test Framework setup

In this blog we will talk about setting up a Test framework.Unit test case helps the application in many ways.For eg in finding Bugs, detecting regression, designing Software Components.

For a desktop based swing application we are pretty much clear on the classes and methods which will need to be added in the test cases.

In a multi tiered J2EE application the question comes is should we write a test case for each layer (Service/ Business /DAO layer) of the application separately?

The answer is ‘YES’ (full proof over engineering) and partly ‘NO’. We will need to write test cases for Service layer and DAO layer separately. We can test the DB system testing by writing test cases for DAO Layer. Similarly we can test the functional behaviour by writing test cases for service layer. A Business layer  is being accessed only by the services layer then we do not need to write a test case for the business layer since service layer is the only consume for which a Test case might have been already defined.

What all options we have, to set up a Testing framework?

Strategies we can go with are

• Create a Test specific DAO spring configuration
• Use different database for executing the Tests cases.
• Use in memory database for eg you can use HSQL DB.
• Write Test specific DAO implementation class: Let’s write a DAO implementation class
• Simplify testing environment by providing empty proxies instead of complex logical units. In other words replace all collaborators with mocks

 OK Now my Testing framework is UP. 

 Do we need to write test cases for all the(non private) method?

No.Test only the core functionality of a class or a method.Or all the methods which we can think of a logical or system operation.

Fine. I have my Testing framework. I have identified the behaviors and methods for which Test case need to be added. what all thing we need to keep in our mind while writing Junit Test cases?

• Write one test-condition per test method
•  When testing output of Collections (List, Set) test for Null and Emptiness
•  Use java reflections for adding new methods into test suites
•  Compare the objects after performing an operation
• Test the exceptions
•  Group logical test cases into test suites
• Check for order of execution of test cases
•  Always include a message to assertion
• Write test cases for each condition
• Write each test case to test only one thing
• The more are the number of test cases the more will get the test coverage
• Make each Test process independent to each others
• Avoid unnecessary preconditions
• Name your unit tests clearly and consistently
• Avoid the use of context with specific setup

That sounds good.We are done with the Unit test cases.After going through couple of testings(Smoke and Sanity) we will be in good shape to move into the Production.

TDD : Most Suitable Scenarios

Having said in the previous blog on TDD : Test Driven Development  now we know the recipe and it’s time understand when to cook this food.

 Points are bulleted as below: 

• When the product is complex 
• Product having lot of dependencies
• When you want to sell your product
• Frequent releases
• Very short development cycle
• Winning the trust from Client
• Agile development
• Enhancing or migrating your legacy code
• When the development is happening on a matured product
• When the emphasis is more on quality than delivering much functionality
• Deadlines are not very much aggressive .
•  Availability of sufficient number of resources
• When you want reduced risk in the Production environment
• Requirements are clear
• When we want more attention to Design  
• Relying more on Continues Integration
• Parallel distributed development
• Large Teams 
• Designing robust software components
• More clarity from the Product management 
•  Suffiicient Test coverage
• Automated regression

I hope things are very much clear now and many of the points above are self explanatory. TDD is followed in most of the big companies like Google, Facebook, Yahoo.
 With this we should be fairly confident in taking decisions in going with TDD which says  'SPECIFY FIRST'.