Sunday, November 29, 2009

Start writing TestCases using JUnit

This article contains the following sections:
  • Why do we need  JUnit?
  • JUnit Basics
  • Install JUnit
  • Write a Test Case
  • Write a Test Suite
  • Run the Tests
  • Resources





Why do we need  JUnit?
JUnit actually helps you write code faster while increasing code quality. Once you start using JUnit you'll begin to notice a powerful synergy emerging between coding and testing, ultimately leading to a development style of only writing new code when a test is failing.

Here are just a few reasons to use JUnit:
  • JUnit tests allow you to write code faster while increasing quality.
  • JUnit is elegantly simple.
  • JUnit tests check their own results and provide immediate feedback.
  • JUnit tests can be composed into a hierarchy of test suites.
  • Writing JUnit tests is inexpensive.
  • JUnit tests increase the stability of software.
  • JUnit tests are developer tests.
  • JUnit tests are written in Java.
  • JUnit is free!
Design of JUnit

    Any class having test methods should subclass TestCase class. It can contain any number of public testXXX methods. Test class can use the setUp() and tearDown() methods to initialize and release any common objects under test. These two methods will be called before and after each test method to ensure there can be no side effects among test runs.


    TestCase instances can be composed into TestSuite hierarchies that automatically invoke all the testXXX() methods defined in each TestCase instance. A TestSuite is a composite of other tests, either TestCase instances or other TestSuite instances. The composite behavior exhibited by the TestSuite allows you to assemble test suites of test suites of tests, to an arbitrary depth, and run all the tests automatically and uniformly to yield a single pass or fail status.




     Install JUnit
    1. First, download the latest version of JUnit, referred to below as junit.zip.
    2. Then install JUnit on your platform of choice:
      Windows
      To install JUnit on Windows, follow these steps:
      1. Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%.
      2. Add JUnit to the classpath:
        set CLASSPATH=%JUNIT_HOME%\junit.jar
        Unix (bash)
        To install JUnit on Unix, follow these steps:
      1. Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME.
      2. Add JUnit to the classpath:
        export CLASSPATH=$JUNIT_HOME/junit.jar
    1. Test the installation by using either the textual or graphical test runner to run the sample tests distributed with JUnit.
      Note: The sample tests are not contained in the junit.jar, but in the installation directory directly. Therefore, make sure that the JUnit installation directory is in the CLASSPATH.
      To use the textual test runner, type:
      java junit.textui.TestRunner junit.samples.AllTests
      To use the graphical test runner, type:
      java junit.swingui.TestRunner junit.samples.AllTests
      All the tests should pass with an "OK" (textual runner) or a green bar (graphical runner). If the tests don't pass, verify that junit.jar is in the CLASSPATH. 
    Write a Test Case
    Here we'll write a test case to exercise a single software component.
    To write a test case, follow these steps:
    1. Define a subclass of TestCase.
    2. Override the setUp() method to initialize object(s) under test.
    3. Optionally override the tearDown() method to release object(s) under test.
    4. Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results.
    The following is an example test case:



    Write a Test Suite
    Here we will write a test suite that includes several test cases. The test suite will allow us to run all of its test cases.
    To write a test suite, follow these steps:
    1. Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests.
    2. Optionally define a main() method that runs the TestSuite in batch mode.
    The following is an example test suite:



    Run the Tests
    To run our test case using the textual user interface, use:

    java junit.textui.TestRunner CalculationTestCase
    The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed.


    Resources
    • JUnit - The official JUnit website
    • JUnit FAQ - Frequently asked questions and answers





      Friday, November 27, 2009

      Web Services Design Decisions

      When designing a Web service, consider the logic flow for typical Web services and the issues they address. In general, a Web service:

      • Exposes an interface that clients use to make requests to the service

      • Makes a service available to partners and interested clients by publishing the service details

      • Receives requests from clients

      • Delegates received requests to appropriate business logic and processes the requests

      • Formulates and sends a response for the request

      Given this flow of logic, the following are the typical steps for designing a Web service.

      1. Decide on the interface for clients. Decide whether and how to publish this interface.

        You as the Web service developer start the design process by deciding on the interface your service makes public to clients. The interface should reflect the type and nature of the calls that clients will make to use the service. You should consider the type of endpoints you want to use—EJB service endpoints or JAX-RPC service endpoints—and when to use them. You must also decide whether you are going to use SOAP handlers. Last, but not least, since one reason for adding a Web service interface is to achieve interoperability, you must ensure that your design decisions do not affect the interoperability of the service as a whole.

        Next, you decide whether you want to publish the service interface, and, if so, how to publish it. Publishing a service makes it available to clients. You can restrict the service's availability to clients you have personally notified about the service, or you can make your service completely public and register it with a public registry. Note that it is not mandatory for you to publish details of your service, especially when you design your service for trusted partners and do not want to let others know about your service. Keep in mind, too, that restricting service details to trusted partners does not by itself automatically ensure security. Effectively, you are making known the details about your service and its access only to partners rather than the general public.

      2. Determine how to receive and preprocess requests.

        Once you've decided on the interface and, if needed, how to make it available, you are ready to consider how to receive requests from clients. You need to design your service to not only receive a call that a client has made, but also to do any necessary preprocessing to the request—such as translating the request content to an internal format—before applying the service's business logic.

      3. Determine how to delegate the request to business logic.

        Once a request has been received and preprocessed, then you are ready to delegate it to the service's business logic.

      4. Decide how to process the request.

        Next, the service processes a request. If the service offers a Web service interface to existing business logic, then the work for this step may simply be to determine how the existing business logic interfaces can be used to handle the Web service's requests.

      5. Determine how to formulate and send the response.

        Last, you must design how the service formulates and sends a response back to the client. It's best to keep these operations logically together. There are other considerations to be taken into account before sending the response to the client.

      6. Determine how to report problems.

        Since Web services are not immune from errors, you must decide how to throw or otherwise handle exceptions or errors that occur. You need to address such issues as whether to throw service-specific exceptions or whether to let the underlying system throw system-specific exceptions. You must also formulate a plan for recovering from exceptions in those situations that require recovery.

      After considering these steps, start designing your Web service by devising suitable answers to these questions:

      • How will clients make use of your services? Consider what sort of calls clients may make and what might be the parameters of those calls.

      • How will your Web service receive client requests? Consider what kind of endpoints you are going to use for your Web service.

      • What kind of common preprocessing, such as transformations, translations, and logging, needs to be done?

      • How will the request be delegated to business logic?

      • How will the response be formed and sent back?

      • What kinds of exceptions will the service throw back to the clients, and when will this happen?

      • How are you going to let clients know about your Web service? Are you going to publish your service in public registries, in private registries, or some way other than registries?