Version 32

    How To Write A Unit Test

     

    Start by extending org.jboss.test.JBossTestCase

     

    JBossTestCase is the standard base test case for jboss junit test cases.

     

    Your testcase needs to extend JBossTestCase to make use of the methods and classes to access the JBoss Application Server.

    public class UnitTestCase extends JBossTestCase
    { 
    
    }
    

    You need to have a constructor which calls the super constructor.

     

    This initializes log4j and the jndi environment from the IntialContext.

     

    public UnitTestCase(String name)
    {
       super(name);
    }
    

    JBossTestCase supplies with:

     

    Access to log4j logging

     

    The getLog() method gets an access to the org.apache.log4j.Logger object.

     

     

    Access to the jboss jmx server

     

    javax.management.MBeanServerConnection server = getServer();

     

    The getServer() method returns a connection to the JMX MBeanServer running on

    jbosstest.server.name(system property), the name of the machine the jboss

    server is on, defaults to getInetAddress().getLocalHost().getHostName())

     

     

    Access to jndi

     

    The getJndiURL() method gets access to the JNDI naming services

     

     

    A method for deploying and undeploying ejb packages.

     

    public void deploy(String name) throws Exception

     

    • Deploys a package with the main deployer. The supplied name is interpreted as a url, or as a filename in jbosstest.deploy.lib or ../lib.

     

    public void undeploy(String name) throws Exception

     

    • Undeploys a package with the main deployer.

     

    public void redeploy(String name) throws Exception

     

    • Redeploys a package with the main deployer.

     

    A one-time deploy and undeploy of packages that are common for all the tests can be done in the setUp() and the tearDown() methods.

     

    More information on this can be found in the wiki section TestsRequiringDeployedArtifacts

     

    Invoke a service

    invoke() method used to invoke any service on the JMX server

     

    invoke(ObjectName name, String method, Object[| ] args, String[| ] sig)

     

    The invoke() method takes in the name of the mbean service, the

    method to be invoked on the mbean service, an Object{FOOTNOTE DEF  } array of arguments for the mbean method

    and a String{FOOTNOTE DEF  } array of types for the mbean methods parameters

    MBeanServerConnection server = this.getServer();
    ObjectName oName = new ObjectName("jboss.system:type=Server");
    server.invoke(oName,"shutdown", new Object[]{}, new String[]{})
    

    Organizing tests into testsuites

     

    JUnit uses reflection to automatically locate all testXXX( ) methods in your test case, adding them to a suite of tests. It then runs all tests in this suite. You can duplicate the default suite( ) behavior as follows:

      
    public static Test suite() throws Exception
    {
       TestSuite suite = new TestSuite();
       suite.addTest(new TestSuite(UnitTestCase.class));
    }
    

    IP Address Parameterization

    The entire testsuite is now parameterized to achieve the flexibility of being able to run on a given IP address or hostname.

     

    Any that has an occurrence of localhost then it needs to be replaced by either System.getProperty("jboss.bind.address" , "localhost") or System.getProperty("jbosstest.server.host" , "localhost"). The former property is for server code and the latter is for client code.

     

    The aim is let the testsuite remain flexible and not bind it to some hardcoded hostname.

     

    Assert Statments

     

    The JBoss convention is that the message states the expected outcome such that the message and condition are consistent. For example:

     

           assertTrue("There are two options", options.size() == 2);

     

    Your message should not print the negative of the assertion:

     

           assertTrue("There are NOT two options", options.size() == 2);

     

    This needs to be consistent otherwise looking at the test one has to  dig through the code to figure out if the message is wrong, the test is wrong, or there is a bug.

     

    Referenced by:*