Monday, June 2, 2008

    Cobertura - Test Coverage Tool

    Many a times we wonder that why a software failed even when we have got everything insured with unit tests. Or some times the situation are when we are not exactly sure why the software is not working the way we want it too even though all the tests are passed. If you have gone through similar situations and looking for an answer, this is it.

    Cobertura is a versatile Java unit test coverage (This blog is about J2EE right) tool. It is a profilic tool that calculates line by line coverage and branch coverage along side other useful metrics like McCabe Complexity Number etc. But the most important idea is that you can see whether your tests are executing your code at each line or not. This becomes very important at the time when you are debugging the unknown error or securing your code for future moderation sensitivity. In any case nothing better than a FREE TOOL. Yes you heard me right its Free. You can download the same from here If you find any dificullty in installing the same for your project, feel free to write to me.

    If you are an advance user and already knows about cobertura than there are chances that you probably might also knows about Clover (Paid Tool Not Good ) Price is very high but the dashboard they provide is execellent.

    So don't be disappointed if you cannot purchase the same, as in the near future I will be updating my own xsl sheet which can generate similar report for you without fuss. And yes that will be absolutely FREE, you can donate some bugs for my beer if you wish. But that xsl is free no questions asked :)

    By the way, this is what Cobertura reports looks like this:

    While my xsl will process the output and provide a report like this:

    Saturday, May 24, 2008



    Java Management Extensions (JMX) technology offers programmers the ability to add monitoring and management to their Java applications. In effect, these APIs allow you to locally or remotely manage anything Java-enabled, from web servers to network devices to web phones. JMX technology is defined by two closely related specifications developed through the Java Community Process (JCP): Java Specification Request (JSR) 3: Java Management Extensions (JMX) Specification and JSR 160: Java Management Extensions (JMX) Remote API 1.0. This tech tip introduces you to the JMX architecture, and shows you how to create a simple Managed Bean.

    With JMX technology, an application, device, or service on one machine (called a resource), can be controlled remotely through the use of one or more custom JavaBean objects known as Managed Beans (MBeans). These MBeans are then registered in a core-managed object server (an MBean server). The MBean server acts as a management agent to any remote managers that want to access the resource.

    The JMX Environment

    The JMX specification defines an architecture in three distinct tiers. The first two levels shown are the instrumentation and agent tiers, which are defined by JSR 3:

    Instrumentation Tier: Resources, such as applications, devices, or services, are instrumented using Java objects called Managed Beans (MBeans). MBeans expose their management interfaces, composed of attributes and operations, through a JMX agent for remote management and monitoring.

    Agent Tier: The main component of a JMX agent is the MBean server. This is a core managed object server in which MBeans are registered. A JMX agent also includes a set of services for handling MBeans. JMX agents directly control resources and make them available for management. The remote management level, the third tier, is partly defined by JSR 160:

    Remote Management Tier: This tier defines protocol adaptors and connectors that make a JMX agent accessible from remote management applications outside the agent's Java Virtual Machine (JVM)*. (Note that JSR 160 defines connectors only.) Connectors are used when the remote client is JMX-aware, and sees the same JMX API as a local client would. Adaptors are used when the remote client is using a generic management protocol such as Simple Network Management Protocol (SNMP) or Common Information Model and Web Based Enterprise Management (CIM/WBEM).

    There are generally three types of developers who use JMX, although one person might exercise all three roles:A developer that writes MBeans to manage resources. Here, JMX technology defines the interfaces exposed for management.

    The developer is responsible for the "glue" between the MBean and the resource itself.A developer that creates and deploys the agent. This person typically performs a number of tasks, including:Creating an MBean server, or using the one supplied by the platform.Registering the MBeans that represent the resources using MBean naming conventions.Configuring the connectors and protocol adaptors supplied by the platform (RMI and SNMP), or adding custom connectors or adaptors if the resources are to be accessed remotely.

    A developer that writes the remote manager. This person chooses the connector or protocol adaptors to interact with the JMX agent, and builds views of the resources managed remotely through the exposed MBeans. There are four types of MBeans, as defined by the JMX specification:Standard MBeans: Standard MBeans are management interfaces that are described by their method names. The methods are then exposed through introspection of the interface. Standard MBeans are the most common type of MBean. Most developers do not need to create any other MBean types.

    Dynamic MBeans: A dynamic MBean implements its management interface programmatically with the DynamicMBean interface, instead of through introspection of method names. To do this, it relies on informational classes that represent the attributes and operations exposed for management. Dynamic MBeans are often used when the management interface of an MBean is not known at compile time -- for example, if it is determined by parsing an XML file.

    Model MBeans: A model MBean is a generic, configurable MBean that applications can use to instrument any resource dynamically. Essentially, it is a dynamic MBean that has been implemented so that its management interface and its actual resource can be set programmatically. This enables any manager connected to a Java dynamic management agent to instantiate and configure a model MBean dynamically.

    Open MBean: Open MBeans are dynamic MBeans, with specific constraints on their data types, that allow management applications and their human administrators to understand and use new managed objects as they are discovered at runtime. Open MBeans provide a flexible means of instrumenting resources that need to be open to a wide range of applications compliant with the Java Management Extensions (JMX) specification.

    The typical process used in creating a JMX-compliant management interface involves at least two steps. The first step is to create an MBean interface, as well as an agent to register that MBean with the MBean server. The next step is to manage the MBean using a remote management application. The JMX specification defines a standard set of connectors that allow you to access JMX agents from remote management applications.

    This is useful because JMX connectors using different protocols provide the same management interface. This enables a management application to manage resources transparently, regardless of the communication protocol used. JMX agents can also be used by systems or applications that are not compliant with the JMX specification, but which support JMX agents.

    Friday, May 23, 2008

    XML Timing Language

    Introduction to XML Timing Language - XTL

    The XML Timing Language (Timesheets) is at present submitted to the W3C org for discussion by the Helsenki University of Technology. This XML Timing Language is used for introducing the timings to the XML document elements.

    Hence XML Timing Language is a separate part of the XML document that specifies the timings for the different elements in the document. The XML Timing Language uses a subset of the Timing and Synchronization module of SMIL 2.0.

    To explain further about the XML Timing Language, think of a webpage that uses Cascading Style Sheets to present the content of a web page. In this way all the contents of the pages are presented all the time. Suppose you want to present only part of the page at an instant and then after a few seconds the other part should be presented, then you can use XML Timing Language to achieve this.

    Just like a slide show you can present contents of the page in different times using the XML Timing Language and the style of presentation is taken care of by the CSS. Hence you should be clear that the XML Timing Language (Timesheets) specify the visibility of the given elements in a document at a moment.

    Timesheets are separate sections of the XML documents. An XML document can have any number of Timesheet elements. It is the container which has other item element which may refer to the media elements. The media elements are divided into static and dynamic elements.

    The static elements are those that contain static images and text and the dynamic media elements are those that contain video and audio. When a static media element is included in the document you have to specify the duration of the element otherwise the element would be displayed indefinitely. In the case of dynamic media elements you need not specify the duration since it will automatically stop when the content of the video or audio is over.
    The timing language elements have attributes like begin and dur. The begin attribute gives the relative starting time of the element with respect to its activation. If you do not specify any attribute value for the begin attribute, it defaults to “0s” which means 0 seconds. The dur attribute gives the duration of the element relative to the start time of the element. For static elements the duration will be indefinite unless the parent element deactivates it.
    The dynamic elements will have the duration as that of the content itself. There is another attribute called the repeat attribute. This gives the repeat count for the element. If the repeat count is positive the element is activated again. You should note that the repeat attribute has some meaning only when it is related to the dynamic content. There is no meaning in repeating the static content. “Indefinite” is also a value for the repeat attribute. This value indicates that the element will be repeated until it is stopped by the parent element.

    The following code gives an example of how the XML Timing Language (Timesheet) is used in a web page.

    <html xmlns="" xmlns:time="">
    <head><style type="text/css">...</style>
    <time:timesheet><time:par><time:item select="#img1" begin="2s"/><time:item select="#img2" begin="7s"/><time:item select="#img3" begin="12s"/><time:item select="#img4" begin="17s"/></time:par></time:timesheet></head>
    <body><div id="content"><p id="title">My Album</p><p id="img1"><img src="image1.jpg" id="image1"/></p><p id="img2"><img src="image2.jpg" id="image2"/></p><p id="img3<img src="image3.jpg" id="image3"/></p><p id="img4"><img src="image4.jpg" id="image4"/></p></div></body></html>

    The above code displays the first image and each successive image is displayed for 5 seconds.

    The tag’s id is chosen to set the duration for the images. The begin attribute is set for 7 seconds, 12 seconds and 17 seconds for the successive images so that the images are displayed for 5 seconds each one by one automatically. With this simple example one can easily understand the power of the Timesheet in a web page. For other elements and attributes and for some simple examples please refer to the XML Timing Language documentation available at “”

    Thursday, May 15, 2008

    Watij - Web Application Testing in Java

    WATIJ stands for 'Web Application Testing in Java'. J2EE deals with creating Web Applications, and like in most cases project teams cannot afford dedicated testers due to "resource limitations", "schedule limitation", "management limitations" and for many other unique explanations and reasons. In some cases where they even do hire manual testers, the job of the tester becomes tedious since most of the team nowadays follows Iterative development model like AGILE, Spiral etc. And thus they need to repeat testing for same set of functionality with every release to ensure that 'new' has not broken 'previous'. And thus with every release the burden on the poor fellow only keeps on getting tougher. Like many other web application, one very important but common feature is Authentication & Authorization. Authentication stands for identifying the users while Authorization refers to validating user's rights within the system. For all these functionalities the tester has to check every time with every release whether they are intact or not. THIS CAN BE AUTOMATED and thus bringing hours of testing effort to be reduced to minutes of self automated runs.

    Now, I know that you know that it can be automated using costly tools like QTP etc. But what I am telling you is that it can be done free of cost using a Open Source tool name as WATIJ. Watij is built over JUnit and thus provides similar interfaces to write the tests. But writing tests are very very simple, when I say simple it means so simple that even my QC and QA who doesn't had previous experience on Java where able to write hundreds of tests. The (wiki) site provides easy tutorials to start with and I am sure you will love it when you start using it.

    But there is a catch, as there are few limitations to the tool at the moment.

    1. Currently it only works with IE
    2. It doesn't works with Applet (Huh, like any body is using it nowadays).

    I tried it with AJAX and it gave good response on many occasions but not sure if it can support advance javascript functionalities like "Drag and Drop" etc. But with all the features it has, mind you it is worth trying.

    Saturday, May 10, 2008

    There exists NO Alternative 4 Unit Testing

    There exists no alternative known for Unit Testing, although there exists '' number of tools which can help you in doing it. Since this blog is oriented towards J2EE, I will talk about JUnit. A tool that has revolutionize the way code is developed (Are you wondering why I didn't said "revolutionize Testing"? Its because its not helpful for tester, it is more helpful for developers). It truly is, it helps developers to eliminate bugs in initial stages. Sach ("Really"), It has been proved over and over again. People, Thinkers, Great mind have always stressed on its usage but we never listened. Let me try to put up the same in another way which may persuade you to think otherwise.

    Lets say, you are building a house (Please start thinking about your dream house which you might have wanted to build or have build already). Now lets start with a land, you will have to buy a land somewhere. Everybody have some choices, specific opinions, lets say some people want their home to be situated in a good colony, some might want it to be far away from city rush. What ever is your choice, tell me would you evaluate the prospect land before buying or after buying? What will happen if you find out after completing your house that the land is not fulfilling your all choices? Either you redo the cycle again (which I am sure most of us here cannot afford to do) or stay with a compromise.

    Lesson 1: Please start testing each unit unit of code before you complete your software. DONOT put off testing until completion, as either it will leave you with a compromise or will require you to do the whole cycle again. You choose, for me choice is simple. :)

    Now, why unit testing is better. I am sure you will be very familiar with the term unit. You use it quite often in your daily life, its a measurement terminology. For e.g. you buy milk 1 litre/day. Litre is your unit to measure the milk quantity. What is the unit for software? Milk quantity can be measured in terms of Litre, Kilo Litre, may be in ounce or kg. There can be many unit to measure the same product. Same way in software you can use NCSS (Non Commenting Source Code) as your unit or function as your unit. In case of JUnit normally function is treated as one unit and test can be written to test each functions.

    Now, lets say you have assigned construction of your house to a vendor (may be due to time shortage). Will you make visits to your house frequently or let the constructor build the complete house and than you will go for inspection. The answer is pretty straight forward, frequent visits will allow you to check the progress made which will result in better control on the construction. That means you can check each "unit" added daily and thus perform better quality control. Same way, if in software construction as well, it will be far easy to write tests for each unit and test it seperately instead of testing software as a bundle (whole).

    Site Info


    Java 2 Enterprise Edition Copyright © 2009 Community is Designed by Bie