Monday, March 15, 2010

Google Web Toolkit (GWT): Uses and Limitations

Google Web Toolkit (GWT) is a web development toolkit is an AJAX framework developed by Google. It’s build using Java as baseline language and allows J2EE developers to implement AJAX behavior in their web application without being expert in
XmlHTTPRequest /JavaScript. GWT comes with it own compiler called GWTCompiler.  All the application development including UI is done using GWT libraries. Once the application is compiled using GWTCompiler, it produces the HTML, JavaScript as part of client side component.

Going little further in deep, an application is divided into tow parts namely client and server components. All the calls made from client to server are asynchronous. Please refer “Starting with GWT” for more details on GWT basic architecture.

Coming to its uses and limitations aspects, let’s go through its uses first and then the limitations.

Usage of GWT:

  1. GWT framework usage Java as baseline language and hence can be easily integrated into Java applications.
  2. Since programming constructs are very similar to Java, learning curve is very small.
  3. By default, all the requests made by client is asynchronous, the application with much complex client server interaction becomes much more efficient without much effort investment.
  4. GWT has plug-ins available for major IDE such as Eclipse, IntelliJ IDEA etc.
  5. GWT comes with its own testing server (Tomcat) called Hosted mode, and provides feature to quickly validate the functionality implemented right through the IDE itself.
  6. Since the application can be run in Hosted Mode from the IDE itself, debugging the application becomes very easy especially the UI components.
  7. Entire application including UI is developed using Java and Style sheets. No JavaScript, HTML is involved in a typical web application developed using GWT.
  8. All the internal URLs of the applications are hidden from the user/hackers and can't be accessed directly bypassing the entry point of the application.
  9. It supports custom calls of native JS functions if any, though not recommended ant not easy.
  10. Other features such as Internationalization (i18n), logging are well supported in GWT.
  11. GWT compiler optimizes the UI code automatically. It removes any dead code during compilation time. Also by setting split-points in the code, it can also segment any download into multiple JavaScript fragments, splitting up large applications for faster startup time.

This is only the first side of the GWT. Let’s look at the other side of it i.e. limitations of using GWT.

Limitations of GWT:

  1. All the client code should be clearly bundled with client package. If any server class is referenced in the client code, results into GWT compilation issue without a very clear message. This becomes trickier as both client and server java files are part of the same source code structure.
  2. GWT compiler output is not very clear and results into very high level compilation errors messages resulting into more effort into finding the root cause of the compilation error.
  3. Every call in GWT application is asynchronous so if there are any synchronous calls required, they have to be grouped in a single call otherwise need to be tricked with group of asynchronous calls.
  4. While writing client side code having multiple asynchronous calls involved, it becomes very tricky to uses out put of the first call into second call.
  5. It becomes more error prone when multiple asynchronous calls are involved in one user request. Developer uses class level variables to pass the details from one call to the other. This way the coding is done without any compilation error. Since the calls are asynchronous, we can’t guarantee the request processing time of individual calls. This leads into inconsistent behavior in the application. If not properly handled, the application may work/may not work as expected depending on the sequence of various individual asynchronous calls processing.
  6. Entire UI is developed using Java (GWT) and Style Sheets. This leads into same issues as servlets (UI elements tightly coupled in Java) and eliminates the advantage of having JSPs.
  7. If the code is running fine in hosted mode, but not running properly in real application deployment, it becomes very difficult to troubleshoot the code as the generated code from the GWTCompiler (which is actually running in production mode) is not very readable.
  8. All the UI is created using generated JavaScript; it becomes very sluggish in case of complex screens. Sometimes it even becomes unresponsive depending on the browser capabilities.
  9. Since all the calls are made asynchrous using JavaScript and also the application page is created using JavaScript, it results into browser alerts quite often stating the page performance.
  10. Creating a screen with complex page layout becomes very tricky as not all HTML elements are supported through GWT.
  11. Novice users result into excessive use of the UI components (various panes e.g. Horizontal Pane, Vertical Pane) and later get confused about their positions and usage as they can be instantiated at any place in the code but only appear in UI at place where added to the base component.
  12. No assistance from UI editors such as Macromedia Dreamweaver.
  13. Generated UI can’t be inspected for its UI components using any current UI inspectors such as IEInspector as all the UI is painted using DHTML/JavaScript.

To summarize, GWT is a very useful framework for application having simple UI with lot of client server interactions involved (where AJAX is a required/applicable feature). It’s not suitable for an application with few requests (one or two) per screen and especially if the screen layout involves huge number of screen components. Many of the times, I have seen wrong usage of GWT where we bear with its limitations but not able to utilize its capabilities. Hence before going for GWT in any application, its applicability should be critically evaluated.

Friday, March 12, 2010

HOT deployment setup from Eclipse to Weblogic server

When we are working on an enterprise application which consists of various modules and in big size, most of our development time is spent in building the application and redeploy on the Weblogic server to validate our changes. While we are updating one or two files at a time, still we are repeating the above steps all the time. This repeating deployment is resulting into slow validation and hence less productivity.

Below is the list of steps, if followed enables the hot deployment of our source code (useful in most of our working scenarios) without affecting any existing processes in place.

Weblogic Side Configuration:
1. Undeploy current enterprise application from Weblogic server.
2. Stop the Weblogic server
3. Create a folder named "MyEar" <Enterprise App Name> in applications folder in your Weblogic domains folder e.g. "C:\bea\user_projects\domains\mydomain\applications\"
4. Open the application ear with some zip utility and extract all the files into "MyEar" folder created in step2.
5. Create a blank file with the name as "REDEPLOY" in MyEar/APP-INF/META-INF folder.
6. Create a folder name "classes" in MyEar/APP-INF folder.
7. Extract the application web module(s) into a folder named "<Web Module Name>.war" in MyEar folder and remove the war file(s) from the folder.
8. Start the Weblogic Server, open admin console, and deploy MyEar<Enterprise application> Application by selecting MyEar<Enterprise application> folder.
9. If the deployment fails detailing any particular module, please open the respective module and correct the MANIFEST.MF file entries.

Eclipse Configuration:
1. Open Eclipse IDE
2. In each java module folder in workspace, create a file named as moduleBuild.xml <we can provide any name of our choice> with details below:

<project name="MyModule" default="hotDeploy" basedir=".">
<property file="build.properties"/>
<target name="hotDeploy">
<delete dir="${dl.dm.dir}\applications\${dep.ear.folder}\APP-INF\classes"/>
<mkdirdir="${wl.dm.dir}\applications\${dep.ear.folder}\APP-INF\classes"/>
<copy todir="${wl.dm.dir}\applications\${dep.ear.folder}\APP-INF\classes">
<fileset dir="${service.project.dir}/${build.dir}/classes"/>
</copy>
<touch file="${wl.dm.dir}\applications\${dep.ear.folder}\META-INF\REDEPLOY"/>
</target>
</project>


3. Create a file named build.properties with entries below(update the values as the local settings):
service.project.dir=../MyService
build.dir=build
dep.ear.folder=MyEar
wl.dm.dir=C:\bea\user_projects\domains\mydomain\applications


4. In each web module folder in workspace, create a file named as moduleBuild.xml <we can provide any name of our choice> with details below:

<project name="MyModule" default="hotDeploy" basedir=".">
<property file="build.properties"/>
<target name="hotDeploy">
<delete dir="${dl.dm.dir}\applications\${dep.ear.folder}\APP-INF\classes"/>
<mkdirdir="${wl.dm.dir}\applications\${dep.ear.folder}\APP-INF\classes"/>
<copy todir="${wl.dm.dir}\applications\${dep.ear.folder}\APP-INF\classes">
<fileset dir="${web.project.dir}/${build.dir}/classes"/>
</copy>
<copy todir="${wl.dm.dir }/applications/${dep.ear.folder}/${dep.war.folder}/jsp/${jsp.dir}">
<fileset dir="${web.project.dir}/WebContent/jsp/${jsp.dir}"/>
</copy>
<copy todir="${wl.dm.dir }/applications/${dep.ear.folder}/${dep.war.folder}/js/${js.dir}">
<fileset dir="${workspace.web.project.dir}/WebContent/scripts/${js.dir}"/>
</copy>
<touch file="${wl.dm.dir}\applications\${dep.ear.folder}\META-INF\REDEPLOY"/>
</target>
</project>


5. Create a file named build.properties with entries below(update the values as the local settings):
web.project.dir=../MyWeb

web.project.dir=../MyWeb
build.dir=build
dep.ear.folder=MyEar
dep.war.folder=MyWar.war
jsp.dir=myJsp
js.dir=myJs
wl.dm.dir=C:\bea\user_projects\domains\mydomain\applications


6. Right click each modules (including both Java and Web Modules)
7. Select properties from the menu
8. Select builds from the properties screen, and click on the "New" button in right side
9. In new screen, select Ant builder and hit "OK"
10. It opens "Edit Launch Configuration" screen.
11. Put any suitable name is the name field
12. In the main tab, browse the respective build xml file (moduleBuild.xml) from the project folder in workspace
13. go to targets tab, set the default target available in first three sections namely "After a Clean", "Manual Build" and "Auto Build"
14. Click Apply and OK to close the window
15. Click OK to close the other underlying window.
16. Once Steps 6-15 are completed for each module; restart your eclipse.


Now you are all set. If you are working on any jsp/js/java file (except EJBBean interface) through your eclipse IDE, your files are hot deployed on the Weblogic server in few seconds. Don’t forget to update Base Module JAR files in deployed MyEar<Enter

Hope this will be helpful in your development activities.

Thursday, March 11, 2010

Profiling Weblogic Application through Eclipse Galileo and TPTP plug-in (Using TPTP Agent Controller)

TPTP (Test & Performance Tools Platform) is an open source project from Eclipse community (http://www.eclipse.org/tptp/). TPTP provides a powerful tool to analyze performance, memory and coverage aspect of a J2EE application. Installing and configuring TPTP in Eclipse is quite straight forward. If the application is a standalone application or running on Tomcat server, profiling the application is a button click activity (right click on the project and select profile). But it becomes bit tricky to profile an application running on Weblogic server as there is no direct adaptor available to achieve the same. To profile a Weblogic application, we need to install and configure TPTP agent controller to work with Weblogic server.

I just thought to list down the steps involved in end-to-end configuration of TPTP along with Agent Controller for Weblogic applications. Here is my list of steps.

1. Installing TPTP Plug-in in Eclipse

  1. Open Eclipse
  2. Go to Help -> Install new software
  3. Click on Add button next to Work with dropdown
  4. Provide details below and hit OK
    1. Name : Any name
    2. Location: http://download.eclipse.org/tptp/updates/
  5. Select newly added site in Work with dropdown
  6. Select the features with desired version from the text area coming downside of the screen.
  7. Click on next and follow subsequent instructions to install TPTP plug-in in your Eclipse.
  8. Once done, restart your Eclipse.

Theoretically this should install TPTP plug-in with Agent Controller but it didn’t work in my case. So as a next step I explicitly installed Agent Controller,

2. Installing Agent Controller

  1. Go to TPTP download site http://www.eclipse.org/tptp/home/downloads/
  2. Download the desired version of Agent Controller by selecting the appropriate platform
  3. Install file is a zip archive, open it with any zip utility and extract to your file system in the desired drive e.g. C:\tptp
  4. It creates a folder as C:\tptp\agntctrl\
  5. Add the bin folder (e.g. C:\tptp\agntctrl\win_ia32\bin) in the path variable.
  6. Execute “SetConfig.bat” batch file from a command line in the bin directory to generate the configuration file for the Agent Controller.
  7. Provide specific details being prompted or hit Enter for default.
  8. This completes the agent controller installation.

Once TPTP and Agent controller are in place, we need to Configure Weblogic server so that it generates the traces for Agent Controller.

3. Configuring Weblogic server

  1. Stop the Weblogic server, if it’s running already.
  2. Open startWebLogic.cmd file from your Weblogic installation in a text editor.
  3. Look for statement as “set JAVA_OPTIONS=%JAVA_OPTIONS%”
  4. Add argument as “-XrunpiAgent:server=enabled” like set JAVA_OPTIONS=%JAVA_OPTIONS% -XrunpiAgent:server=enabled
  5. Save and close the CMD file.

At this point you are all set to profile your Weblogic application running within Eclipse (If not done already follow the steps to run the application with Eclipse). Below are the steps to start profiling your J2EE application within Eclipse.

4. Profiling the application through Eclipse

  1. Open your Eclipse IDE
  2. Start the Weblogic server hosting the J2EE application.
  3. Wait for server to completely start.
  4. Click on the icon for profile next to run icon in command bar of the eclipse.
  5. Click on “profile configurations..” option
  6. It opens a new window with some options in left pane.
  7. Double click on “Attach to Agent” option
  8. It opens dialogue for new configuration. Fill the details as below
    1. Name: Any descriptive name
    2. Leave to host tab as default
    3. Go to Agent tab
    4. You should see the agent controller check box preceded by a “+” sign, if you don’t see the agent controller being list, click on the refresh button. If still don’t see the agent controller, your agent controller may not be running. In this case start the Agent Controller manually by running “ACServer.exe” from bin directory of Agent Controller installation.
    5. Click on the “+” sign to expand and select one are more analysis type to be performed e.g. Basic Memory Analysis, Execution Time Analysis etc.
    6. Once you select the analysis type, “Profile” button in the bottom is enabled.
    7. Click the button and start analyzing your application.

This completed all the configurations required. If interested in more on profiling techniques, wait for my coming postings.

Wednesday, March 10, 2010

J2EE Design Patterns and my opinion about their usage

First let's talk about design patterns itself. It's made of two words design and pattern. Design refers to the application design which leads into implementation and Pattern is something which is recurring (repeating) in the design/implementation. While working on a project or multiple projects, if you find some kind of design/implementation is repeating, we can say that it's a pattern followed in the application. J2EE design patterns are nothing but most recognized application design patterns across various J2EE applications in the world.

It was my second project (way back in 2002), I learnt about most of the J2EE design patterns. At that time, typical n-tier architecture was being followed in IT industry. When I say typical n-tier I don't mean "n" being 3 or 4 but I mean n being something like 10 or more. It has changed recently and now we are following simplistic design with whole lot of third party frameworks. For example we are not creating facade tier, data layer etc., instead we have started using frameworks like spring and hibernate. Design patterns become more applicable in typical n-tier architecture but it doesn't mean that they can't be applied in simple application design. I am not in favor of adopting several design patterns in the application but I would prefer that any selection of design patters are critically reviewed against its suitability in the application design.

Here is what I think about different design patterns and possible suitable uses of them.

1. Model-View-Controller (MVC) Design Pattern: Once we start following OOAD principles, the very first thing we learn in about an object. An object is an entity which has a very clear defined responsibility with lowest possible granularity. If applying the same concept at little broader level, it results into MVC design pattern. Under MVC design patters, we classify our classes in three buckets namely model, view and controller. Model is the category of classes which represent enterprise data with no to minimum logic e.g. data transfer objects. Controller is the category of class(es) which control the navigational logic and initiate the business process e.g. servlet controller. View is the category of classes used in presentation of the enterprise data in form of an information e.g. JSPs.
This is my favorite design pattern with one confusion. If I start categorizing my all classes in above three buckets, I am unable to think a right place for the classes having pure business logic. Therefore for my own ease, I introduced a fourth category called "Business" and named this design pattern as MVCB design pattern. I am totally onboard with this design pattern and can't think of any reason for not using it.


2. Factory Design Pattern: As the name suggests, it's a pattern when we implement a functionality similar to factory. Factory means any factory which produces goods in mass e.g. Toy Factory, Car Factory etc. The idea taken from factory is you pass some instructions to the factory and you get your desired product(obviously if that factory produces it) without much bothering about internal steps taken within the factory. Similarly in J2EE world, a factory class has responsibility to create different objects based on certain inputs. I think this was/is the most popular J2EE pattern in a typical n-tier architecture. This was mostly being used in instantiating Value Objects or Command objects based on certain parameters.


I am not against using this design pattern but I don't suggest to use it for above said purpose e.g. for creating value objects or command objects. There is no value in instantiating a value object or command object or any other similar object without having complex logic involved in creation of the object itself through factory, instead we can simply call the required class constructor. We should use a Factory only when we have complex/average logic involved in creation of the object itself e.g. database connection session object creation. To create a session object, we need to pass all different arguments, perform data source lookup (as applicable) etc. In this scenario, I am on to create a session factory (follow factory design pattern).

3. Facade Design Pattern: Facade design pattern is a pattern when you have complex business objects involvement in processing a single request. It becomes messier and less maintainable if you expose all business objects to the requesting body. This also results into more network traffic if you are using Service Oriented Architecture (SOA). Instead of exposing all business objects to the client component, you can create a wrapper implementation involving all required business objects and give handle of this wrapper object to the requesting body (client). This wrapper implementation is nothing but a facade to make the business processing requests and this design pattern is called Facade design pattern.

As mentioned above, this pattern is more applicable when you are having complex involvement of business objects in individual business request processing. Its becomes more applicable when this kind of behavior is implemented using Service Oriented Architecture (SOA). This was again a very popular pattern in typical n-tier applications specially implemented using EJBs. I find rare scenarios in recent applications where Facade design pattern becomes applicable.

4. Singleton Design pattern: Singleton design pattern is all about restricting the number of instances of a particular class in the application. This is done by hiding the class constructor and exposing some static method which either exposes the only instance of the class or performs required operations on the single instance of the class.

Typical candidate for Singleton design pattern is connection factory class where you would not want to instantiate multiple instances of the factory class and rather you would like to use the single instance of the class throughout the application. If I look at the recent trend, I find that with the introduction of frameworks like Spring, this design pattern is not being used explicitly. This becomes silent pattern in the application automatically.

5. Visitor Design Pattern: Again as the name suggests, visitor design pattern is all about traversing an object graph. If your application uses object with multiple depth involving collection of objects at any level, you end up writing logic to traverse through the object graph including every object irrespective of its level for its processing. If you generalize the concept irrespective of the underlying objects, it becomes Visitor Design Pattern.

This design pattern becomes very useful in dealing with big object graphs with no available traversing mechanism. With introduction of aspects, we are able to insert processing logic at method call levels staying out of the object. There are also some other frameworks available which enable you to take your processing logic from the object graph level e.g. to persist a database object along with its dependent collections, we can think of using visitor design pattern. But before going for it, I would evaluate uses of any good ORM such as Hibernate, Toplink, BC4J which takes care of my requirement altogether. I would go for visitor design pattern only when I have applicable scenario and also I need to write my processing logic explicitly.

There are some more design patterns followed rarely now a days. I would not like to go in much detail of them. Below is the list of some of them.

1. Service Locator Design Pattern: This is a design pattern where we create classes with responsibility to locate my service classes. This used to be/is very useful in case of application using EJBs. In such applications, we can create EJBLocators which will perform the lookup and return the EJB handle. In normal enterprise application, I am not inclined to use this design pattern as there is no to rare use left for it now a days.

2. Command Design Pattern: Under this design pattern, we introduce and extra layers called command layers. This layers behaves as a glue between requesting object (client) and service processing object(business object). Other than extra decoupling of business logic with client/presentation logic, I don't see any advantage from using it. Until my business calls are very complex and intrusive, I will not go for this design pattern anymore.

3. Delegate Design Pattern: Under this design pattern, we create classes with only responsibility to delegate to requests from one class(layer) to other class(layer). Since delegates don't carry out any extra value, I am not inclined to use this design pattern anymore.

4. Helper Design Pattern: Under this pattern, we takeout part of the processing logic from the main class and put in a secondary class called Helper. Helper classes are very similar but may use some system, business objects as opposed to the Util classes e.g. we can create StrutsActionHelper class to supplement struts action logic. Only difference between a typical Util class and this helper is that this helper can use all struts framework objects while its not advised for the Util class.

5. Data Access Object (DAO) Design Pattern: Under this pattern, we typically write a call having responsibility to initiate any database calls. As mentioned earlier, I am on to use ORM than implementing a DAO.

Some interesting facts about Math of Numbers (Arithmetic)

We do apply math of numbers(Arithmetic) on regular basis in our day to day activities where we are buying any goods, scheduling any even in the day, counting the remaining days for a party etc. This has become integral part of our thinking. I also do the same. Today I took a pause and started thinking about some interesting facts about this Arithmetic and here is what came to my mind.


1. Multiply any number by 3 and sum all individual digits of the result to make it single digit, it's always 3 or 9

Example
  • 79*3= 237 Sum->2+3+7=12 -> 1+2=3
  • 8547*3=25641 Sum->2+5+6+4+1=18 ->1+8=9
  • 896512*3=2689536 Sum->2+6+8+9+5+3+6=39 ->3+9=12 ->1+2=3


2. Multiply any number with 9 and sum all individual digits of the result to make it single digit, it's always 9.

Example
  • 15*9 = 135 Sum-> 1+3+5=9
  • 1764*9= 15876 Sum-> 1+5+8+7+6=27 ->2+7=9
  • 96862*9=871758 Sum-> 8+7+1+7+5+8=36 ->3+6=9

3. Square of any number having last digit as 5 is always ending with 25(square of 5) and the value preceding 25 in result is multiplication of value preceding 5 by its own increment by 1.

Example
  • 25*25 =625 -> It's ending with 25 and preceded by 6 which is nothing but 2*(2+1).
  • 925*925=855625 -> It's ending with 25 and preceded by 8556 which is nothing but 92*(92+1)
  • 4565*4565=20839225 -> It's ending with 25 and preceded by 20839 which is nothing but 456*(456+1)

4. Square of a number having all digits as 1 is always starts and end with 1 and the it has always less than one digits of the starting number digits. Also it's an ascending number sequence till middle and then descending number sequence.

Example
  • 11*11 =121 ->Its 3 (2*2-1) digits, starts and ends with 1 and 12 is ascending order digits group and 21 is descending digit group.
  • 111*111=12321 -> Its 5 (3*2-1) digits, starts and ends with 1 and 123 is ascending order digits group and 321 is descending digit group.
  • 11111*11111=123454321 -> Its 9 (5*2-1) digits, starts and ends with 1 and 12345 is ascending order digits group and 54321 is descending digit group.

5. Pi is number which is both irrational and transcendental. Out of its known decimal digits, there are no repeating patterns. There is no zero its first 31 decimal digits. Notice yourself
from the below:

  • Value of the Pi up to its 31 decimal digits is 3.1415926535897932384626433832795 (no zeros)
  • Value of Pi up to its 100 decimal digits is 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679

6. Most interesting thing I find in math is about its numeral system. No matter which numeral system we pick e.g. binary, ternary, octal, decimal, hexadecimal, we can apply same principle of mathematical operations just keeping the numeral system base in mind.

Example
Let's try adding two set of numbers (8,9 and 436,753) through different numeral systems.

Binary
1000 110110100
+1001 +1011110001
------ -----------
10001->17(Decimal) 10010100101 -->1189(Decimal)

Ternary
22 121011
+100 +1000220
------ -----------
122->17(Decimal) 1122001-->1189(Decimal)

Octal
10 664
+11 +1361
------ -----------
21->17(Decimal) 2245 -->1189(Decimal)

Decimal
8 436
+9 +753
------ -----------
17 1189

Hexadecimal
8 1B4
+9 +2F1
------ -----------
11->17(Decimal) 4A5 -->1189(Decimal)


The fact I am trying to illustrate here is that I am applying the same mechanism to add numbers one digit at a time starting from right to left and taking the carry overs if applicable. We can perform all other operations such as subtraction, multiplication and division as well. Not to worry about the numeral system. Just need to take care of the basic principle.

Tuesday, March 9, 2010

Overcoming hurdles of Unit Testing

First time when I started writing Unit Test cases in Java, it wasn't because of interest or belief but more because of agreed deliverable of the project. Since it was imposed, I didn't realize the value. I created some Unit test cases just as a post development artifact to show the work done. The test cases weren't exhaustive and obviously I wasn't looking for any benefit from them. After certain level of development, my test cases (which were not very useful to start with) became totally useless. I didn't go back to update/correct/complete them in time. I started showing this failure of the test cases as example against writing the Unit test cases with some success as well.

I am sure, I wasn't the only one at that time with this mindset. There would have been many similar people at that time and even there would be many today as well. But today I am a changed man. I do understand the benefit of writing test cases and turning to be an advocate for the same.

Most of the time we fail in achieving the desired results because of several reasons. Some of them could be mindset related as below:
  • We don't believe in action being taken.
  • We don't see the value especially to ourselves.
  • We don't take it as our responsibility to make it successful.

Here is the list of bigger hurdles (I think of) in Unit Test success and suggested mitigation plans.

1. Lack of understanding the "Unit": Most of the time we start thinking of a whole business case as a testable unit. This leads into enormous number of complex test scenarios and multiple integration points. Having complex scenarios with uncontrolled integration points, it becomes almost impossible to write an Unit Test case.

To solve this problem, let's understand the Unit. We can imagine units as atoms which are the smallest possible particle in the coding world but self-contained (I am not saying electrons/protons or even molecules). One Unit of code should have smallest set of processing logic which takes the system from one state to another. Let's take an example of car. If we consider Car as a business case, we can consider wheels, head light, tail light, steering wheel, horn as it units. Each unit has certain specification and defined responsibility. If I need to write test case for a headlight, my some of the possible scenarios could be as below
  • It turn on if input supply is on
  • It turns off it input supply is off
  • It shows high beams with input type as high beam
  • It shows low beams with input type as low beam
Once we have clean units defined, it's become very intuitive to come up with the possible test scenarios and creating test cases against them.

2. Unit Testing and Development are two different activities: As a developer I can always argue that I am not responsible for writing Unit test case as there is a dedicated QA team. This leads into passive response from the developers in creation of Unti test cases while they are the best people to come with test cases as they understand the code best.

Unit testing should be treated as the integral part of the development. Also developers should implement the functionality with the mindset of unit testing. The source code should be as modular as possible with clear defined responsibilities for each unit. Unit testing can't be successful by carrying out Unit testing as a secondary task; carried out after the development. Instead Unit testing should be part of the development from the day one and carried out with the same developer (if possible).


3. Functionality is more important than Unit Testing: When working on a project with tight deadline, developers tend to meet the functionality ignoring the test cases. Once the functionality is implemented, momentarily they celebrate, but very soon it turns into disaster after several bugs are discovered. Fixing the bugs at last moment without having sufficient Unit test cases becomes more risky. It becomes very tough to overcome the scenario even by putting extra help and effort.

I agree that Unit testing is not an end user deliverable but at the same time its lifeline for the end user deliverable. As we won't drive a car whose breaks/gas/parts are not fully tested, we shouldn't expect the user the start using an application which is not systematically tested. We should consider Unit testing equally important as developing the functionality. I am sure; you will start realizing the benefit as soon as you start following it with full belief.


4. My input/output is varying all the time: As soon as it comes to unit testing, first argument we listen is the input data is continuously changing. My test case might work today but it may fail tomorrow just because of the data. Also sometime we listen that output is dynamic, then how to validate that.

Here I would like to emphasize one thing. Unit testing is not about how to test the unit. As a developer, you are doing it all the time to validate your implementation (if not, even more is missing). Unit testing is all about automating the test scenario at development time and later reuse it as regressive test suite. Once we have clean definition of Unit, we need to prepare our own test data to meet all our test scenarios and use that test data in Unit test cases. Output of the unit is a derived value based on the input and hence we should be able to device the expected outputs. If we are using some functions such as Random, we need externalize it and replace it with genuine inputs. This way I can say that we clearly understand the concept of unit testing, we will never talk about dynamic input/output. Also as I mentioned above, it's an activity to be performed along with development, not separately.

I hope this is helpful.

utPLSQL vs Code Tester for Oracle

I have been using several Unit testing tools to Unit test various code blocks in J2EE application. Recently I started looking into possibility of testing PL/SQL blocks and I found two tools name utPLSQL (http://utplsql.sourceforge.net/) and Code Tester for Oracle from Quest (http://www.quest.com/code-tester-for-oracle/). Interestingly both are developed by "Steven Feuerstein" but utPLSQL is free while Code Tester For Oracle is a commercial tool from Quest.

After playing with both the tools in last couple months, this is what I found as the take away.

  1. utPLSQL is unit testing tool with no fancy GUI available and is similar to JUnit in Java in many aspects while Code Tester for Oracle comes up with a sophisticated UI.
  2. utPLSQL has building blocks required to create Unit test cases for PLSQL blocks with minimum to no extra assistance for the developer/tester in creating the test cases. On the other hand, Code Tester for Oracle performs heuristic analysis of the deployed database schema beforehand and provides lots of assistance during preparation of the test cases.
  3. utPLSQL test cases can be executed from the SQL prompt or some similar means while code tester supports both command line and GUI options.
  4. utPLSQL presents the test results in plain format in test running console while Code Tester has beautiful Test Results UI with RED & GREEN dots.
  5. in utPLSQL, a tester/developer has to code each and every test related steps using utPLSQL components while in Code Tester For Oracle, a tester/developer can feed the input/output data and test case might be done(so simple). Also code Tester For Oracle provide hookup points in the generated test case to embed any extra custom logic which is not supported by Code Tester for Oracle GUI.
Thus it seems like Code Tester for Oracle is a trivial choice as a PLSQL code testing. Let's look at the other side of the comparison.

  1. utPLSQL is a free tool while Code Tester for Oracle is a commercial product from Quest, which means you need to spend initial money for Code Tester for Oracle. Therefore before opting for Code Tester for Oracle, one need to carry out the cost vs. value analysis first.
  2. Since utPLSQL comes with building blocks only, it gives you full control on your testing logic while we need to find ways in Code Tester for Oracle to perform certain kind of test operations.
  3. utPLSQL test case code is much cleaner as compared to test code generated from Code Tester from Oracle as it consist of several lines of codes related to GUI of the Code tester for Oracle. This means test case code prepared through utPLSQL is more maintainable then the test case code generated through Code Tester for Oracle.
  4. Since test code generated from Code Tester from Oracle has code related to the GUI, it becomes difficult to manage through command line though it supports command line operations through certain extent.
  5. Again because of the GUI tied with the code tester, it becomes little tricky to integrate test cases/test suited created through Code Tester for Oracle as part of regular build environment such as Cruise Control or Hudson.
Thus we can see that it's not trivial choice as it sounded through the middle, but both the tools are having their pros and cons. Using utPLSQL results into more maintainability while using Code Tester for Oracle results into higher productivity. One needs to carefully evaluate all the side against his/her requirement before opting one versus other.

Steps to configure Start Team Client 2008 with Eclipse Europa, Ganymede or Galileo

If you are using Star Team as version control and Eclipse as IDE, probably you would like to configure Star team plugin in your Eclipse to make your life easier. If you intend to do so, you may follow the steps below:

Installation:

  1. Open eclipse
  2. Click on Help > Software updates > Find & Install
  3. Click on new site
  4. Enter “Star Team” as site name and provide URL as “http://altd.borland.com/update/eclipse3.3/site.xml“ for Eclipse Europa and "http://altd.borland.com/update/eclipse3.4/site.xml" for Eclipse Ganymede or Eclipse Galileo.
  5. From list of available modules, select Star Team Client related option.
  6. Click on install buttons in subsequent screens.
  7. Restart the eclipse IDE

Configuration of repository:

  1. Start eclipse IDE
  2. Click on Window > Open Perspective > Others
  3. Select Star team classic view
  4. Go to Server Explorer view
  5. Click on the icon to add new repository in the top to create new repository connection
  6. Provide information as below
    1. Server Description : Any Description
    2. Server Address: IP address of the Star Team Server
    3. TCP/IP endpoint: Port of the Star Team Server e.g. 49201
  1. Provide your star team user id/password in credential fields
  2. Click on finish

Usage:

  1. Start eclipse IDE
  2. Click on Window > Open Perspective > Others
  3. Select Star team activity view
  4. Browse through the required folder in server repository
  5. Select source folders
  6. Right click and select “Export as project”
  7. Once the projects are checked out in the workspace, we can right click the folders and select synchronize
  8. At this point, you will be able to perform all version control operation through eclipse itself based on your privileges.
This completes all the steps and removes the hassle in all version control activities e.g. check-out, check-in, merge and synchronize. Above and all, this all can be done using the development IDE (eclipse).

NOTE: Please review license terms and conditions and proceed only when you agree them.

Setting up Weblogic server in Eclipse Galileo

If you are working on an Enterprise/Web application using Weblogic as your development server and Eclipse Galileo as IDE, you might want to integrate your eclipse with your Weblogic server by following simple steps below.

  1. Change Eclipse memory settings by updating the properties of eclipse.ini file -Xmx768m -Xms256m
  2. Make sure this configuration (-Dsun.lang.ClassLoader.allowArraySyntax=true) is there, if not add it and save the file.
  3. Make sure you have configured your Weblogic server in "Development" mode. If node done, please change the configuration.
  4. Start Eclipse
  5. Go to Window -> Preferences -> Server -> Installed Runtimes -> Add
  6. In the dialog "New Server Runtime", there is a link "Download additional server adapters". Click it, and Eclipse will search on the Internet for additional server adapters. When it's done, select “Oracle Web Logic Server Tools” (or more appropriate one, if you get one) and install it.
  7. Alternate to step 5, you can add http://download.oracle.com/otn_software/oepe/galileo as updated site in Eclipse and install the Eclipse pack from Oracle.
  8. Restart your Eclipse after installation.
  9. Open server view as Window ->Open View -> Others -> Server ->Servers
  10. Right click on the pane, and select new server
  11. In the next screen, select your JRE e.g. JRE 1.5 and Weblogic installation directory e.g. C:\bea\weblogic.
  12. Click next
  13. In next screen, provide the Weblogic domain directory e.g. C:\bea\weblogic\myprojects\domains\mydomain, provide the Weblogic port e.g. 7001 and user id/password for the Weblogic server.
  14. Click finish.
  15. Double click on the server; it will open server details in the editor. Make sure publish automatically check box is check. If not checked, check it, save and close it.
  16. At this point, you can see Weblogic server listed in server pane.
  17. You can right click the server and add/remove projects from your workspace to this server.
Now you are all set to start, stop your Weblogic server from your Eclipse IDE. Also no more builds and manual deployments from the back-end. Any changes made in your work space, will automatically be published on your Weblogic server.

I hope this is helpful and reduces some of your frustration in switching between multiple windows.

NOTE: Please review license terms and conditions and proceed only when you agree them.