J4ONet Description

    Junit Diagnostic Workers




    Why Bother With Junit Diagnostic Workers?

    Why Do I Need Tests?

      Open Distributed Processing (ODP) systems are made up of many independent components. For example, a commerce site may use several web servers, application servers, and databases. It is not hard to imagine that each of the systems involves several independent subsystems. In the case of most large databases, many have a separate database servers, socket connection agents, transaction servers, etc., and each of these systems can operate independently.

      When a component of an ODP system fails, the effects can range from devastating to unpredictable. If one of the databases goes down, many components might fail over to a standby database, but several threads may hang while waiting for dead transactions to complete. Next, you will get a call from customer support saying that "People are having problems with the site." No further elaboration will be possible or offered. If you test the site, you may notice that one out of so many attempts will seem to hang as you get a hung thread from pool, but this brings you no closer to understanding what is going on.

      The fact is that ODP systems require complicated diagnostics. It is essential to be able to access and test each component. On a large system, this could mean literally hundreds of tests. In crisis moments, such as trying to figure out why "People are having problems with the site," you will need to be able to run these tests as quickly and reliably as possible.

    How Does Junit Help?

      How do you quickly run a battery of test and gather results from the tests which failed? You could script them, but be honest; that would take time and be one of those back burner projects that are never up to date.

      Testing and keeping current tests is something that the Junit Project has helped many developers with. It provides a flexible and powerful framework for developing tests. It is easy to use and developers can implement it quickly.

      Further more, many tools integrate Junit support. ANT allows you to put Junit tests in your ANT build scripts. IDE's like SUN ONE (The IDE formally known as Forte), JBUilder, and VisualAge all can use Junit tests. Junit is the de facto standard for implementing component tests.

      Most of the focus of Junit has been testing components, such as Java objects. But, there is no reason why one couldn't test an ODP system's components too. Instead of a test that checks if a class works correctly, create a test that makes sure that an HTTP server is running correctly. In fact, this is easier; because most ODP systems use the same standards based components. Generic tests can be used across many systems. Tests that can check HTTP, JDBC, and RMI connections can be used across many sites with only changes to a configuration file.



    So How Does This Thing Work?

    The Structure

    • TestCase:

      Junit has a TestCase class that all tests extend.

    • Service Tests:

      These tests are stateless and contain common functions for their realm. Developers can use these tests to create specific tests for their specific realms. For example, if you needed to make sure that a database always returned a specific table structure, you would extend the JdbcClientTest. Currently, there are three realms handled under the JunitDiagnosticWorkers package:

      • HTTPClientTest
      • JdbcClienTest
      • RemoteObjectTest

    • Basic Tests:

      These are stateful objects, meaning that calls to the object can affect subsequent calls. For example, the stateless service test HTTPClientTest will have a test to try and connect to a specific URL. If it fails, that will have no effect on another call to the same function.

      The BasicHttpUrlTest is different. It has a function to set the URL to test. It has a list of tests to run on that URL. It will retain the specific URL until it is reset.

      These stateful basic tests will allow you to script most of your tests.


    The SuiteAssembler

      Junit runs TestSuites, which are collections of tests. An ODP system needs a way of organizing all of its necessary tests. I bet you can see where this is going.

      SuiteAssembler takes an XML file and returns a TestSuite. Thus you can create an XML file and have a full test quite ready to test most functions of an ODP system. Changes in the future will not require recompiling, but only changes to an XML text file. This ease of maintenance should help prevent the tests always being out of date.

      By default, the SuiteAssembler will look for the XML document TestSuite.xml in the working directory. Calling any of the set document functions can change this behavior.


    TestSuite.xml

    The XML Format

      The DTD for the TestSuite.xml is simple:

    Example TestSuite.xml



    The Basic Tests


      BasicHttpUrlTest:
        The BasicHttpUrlTest bean is very simple. It has a get/set for a URL as a string. So to initialize this object in the TestSuite.xml invoke the setUrl(String s) method. It contains one test, which will try to access the URL and check for an HTTP status of 200.

      BasicJdbcTest:
        The BasicJdbcTest bean has several attributes that need to be set to initialize it:
        • setDriverName(String s): name of the JDBC driver class to use.
        • setUrl(String s): URL for the JDBC driver to connect to.
        • setUsername(String s): username to connect with.
        • setPassword(String s): password to connect with.
        • setSelectSql(String s): a select statement to issue to the database once a connection is established.
        • setSelectThreshold(int i): the minimum number of rows that need to be returned by the select statement (Defaults to 1).

        This bean will run two tests: CanConnect, which will return a success if the bean can connect to the database, and SelectGood, which will return a success if the select statement returns at least as many rows as the threshold.

      BasicEjbTest:
        The BasicEjbTest bean has several attributes that need to be set to initialize it:
        • setJndiName(String s): the JNDI name of the EJB to test.
        • setProviderUrl(String s): this URL will be the Context.PROVIDER_URL used by the bean to connect to the EJB, so this should be the URL of the EJB's RMI server. If this is null, it will use whichever value is already in the default InitialContext.

        This bean will run one test, AccessEJB, which will try to get a remote handle to the EJB and see if it can return the EJB metadata, via a getEJBMetaData() called on the remote object.

      FailedMessageTest:
        The FailedMessageTest bean isn't really a test. You can call setMessage(String s) on it and it will always fail with this message. This is handy for implementing messages in the failed test output.



      Computer, Run Level 1 Diagnostics

        Okay, I will be honest. One of the big motivations for this package is to make my systems work like those cool ones on Star Trek. You know, the computers on Star Trek were usually the first to know that they were having a problem. And, it wasn't some General Protection Fault or Blue Screen of Death. The computer would report to the captain that is was having a problem and some specific diagnosis. Think about it, on Star Trek you would find navigators, engineers, doctors, scientist; but, you never saw any SysAdmins. It's because they didn't need them, they had computers that could diagnosis and heal themselves. When you think about that, the Transporter doesn't seem as impressive as the computer.

        To get up and running with an example, download the example TestSuite.xml file into your working directory. Make sure that both the JMX4ODP and jUnit jars are in your classpath. Then type:

        java junit.swingui.TestRunner org.jmx4odp.junitDiagnosticWorkers.SuiteAssembler

        If this is still much manual labor, just go to your:

        bin/diagnosticWorkersDemo

        now run

        start.bat or start.sh

        It will do the same thing. What are you waiting for? Go right now and give it a try! Puh-lez, if you are in a windows manager, it is point and click testing! Now go!

        This will start up the graphical jUnit TestRunner which will load the JMX4ODP SuiteAssembler test. The SuiteAssembler will look for a TestSuite.xml in the local directory and find the example one you just placed there. Now the TestRunner will try to access all the web servers in the TestSuite.xml and report which worked and which didn't.