avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hamm...@apache.org
Subject cvs commit: jakarta-avalon-phoenix/src/documentation/content guide-punit.xml book.xml for-developers-alternate-kernel.xml
Date Sat, 30 Nov 2002 08:43:43 GMT
hammant     2002/11/30 00:43:43

  Modified:    src/documentation/content book.xml
                        for-developers-alternate-kernel.xml
  Added:       src/documentation/content guide-punit.xml
  Log:
  Punit guide added. Small mods to beanshell words.
  
  Revision  Changes    Path
  1.2       +1 -0      jakarta-avalon-phoenix/src/documentation/content/book.xml
  
  Index: book.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/documentation/content/book.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- book.xml	18 Nov 2002 14:18:18 -0000	1.1
  +++ book.xml	30 Nov 2002 08:43:42 -0000	1.2
  @@ -17,6 +17,7 @@
   <menu-item href="bdg/index.html" label="for Block Developers"/>
   <menu-item href="mx/index.html" label="Management Guide"/>
   <menu-item href="guide-example-configuration.html" label="Example configuration"/>
  +<menu-item href="guide-punit.html" label="PUnit unit testing"/>
   </menu>
   <menu label="Reference">
   <menu-item href="api/index.html" label="API Docs"/>
  
  
  
  1.2       +8 -1      jakarta-avalon-phoenix/src/documentation/content/for-developers-alternate-kernel.xml
  
  Index: for-developers-alternate-kernel.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/documentation/content/for-developers-alternate-kernel.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- for-developers-alternate-kernel.xml	18 Nov 2002 14:18:18 -0000	1.1
  +++ for-developers-alternate-kernel.xml	30 Nov 2002 08:43:42 -0000	1.2
  @@ -26,13 +26,20 @@
           interacting with the block's methods from its service.
         </p>
         <p>
  -        To create a beanshell capable kernel, place the bsh-1.2b6.jar from
  +        To create a beanshell capable kernel, place the bsh-1.2b7.jar from
           <link href="http://www.beanshell.org/download.html">here</link> in
the 
           lib directory of phoenix before building it.  You will need to edit the 
           'beanshell.jars' and 'kernel.impl.class' parts of the ant.properties file.
           You may also want to add your own convenience bsh scripts to the 
           src/bsh/ directory.
  +      </p>
  +      <p>
  +        Alternatively, with a binary distribution of Phoenix, it is sufficient 
  +        to just place the beanshell jar in the lib directiory of an unzipped
  +        Phoenix.  To enable it, edit conf/kernel.conf and change the kernel line
  +        to use the BeanShellKernel.
         </p>            
  +      
       </section>
       <section><title>Beanshell enabled, remotely accessible kernel</title>
         <p>
  
  
  
  1.1                  jakarta-avalon-phoenix/src/documentation/content/guide-punit.xml
  
  Index: guide-punit.xml
  ===================================================================
  <?xml version="1.0" encoding="ISO-8859-1"?>
  <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "document-v11.dtd">
  <document>
    <header>
      <title>Guide - PUnit</title>
      
    <authors><person name="Paul Hammant" email="Paul_Hammant@yahoo.com"/></authors></header>
    <body>
      <section><title>Introduction</title>
        <p>
          Phoenix has a component/lifecycle aware unit test framework called PUnit.  It has
no requirements on 
          external meta information.  As such it could be used for unit testing for a wide
range of Avalon-Framework 
          enabled components.  Having said that, usage requires some knowledge of multi component
applications and
          the order of component lifecycling.
        </p>
      </section>
      <section><title>Example Usage</title>
        <p>
          There is a unit test framework for Phoenix called PUnit.  It is used for pseudo
in-container testing of Phoenix 
          components.  The main class PUnitTestCase should be extended by the developer, some
manual setup done, then 
          normal assertXXX() testing.
        </p>
        <p><strong>Test component (from Phoenix's own PUnit TestCase)</strong></p>
     
        <source>
  public class TestBlock
          implements Serviceable, Configurable, Initializable, Contextualizable, LogEnabled
  {
  
      public ServiceManager m_serviceManager;
      public boolean m_initialized;
      public Context m_context;
      public Logger m_logger;
      public Configuration m_configuration;
  
      public void service( final ServiceManager serviceManager ) throws ServiceException
      {
          m_logger.info("service");
          m_serviceManager = serviceManager;
      }
  
      public void initialize() throws Exception
      {
          m_logger.warn("initialize");
          m_initialized = true;
      }
  
      public void contextualize(Context context) throws ContextException
      {
          m_logger.error("contextualize");
          m_context = context;
      }
  
      public void enableLogging(Logger logger)
      {
          m_logger = logger;
      }
  
      public void configure(Configuration configuration) throws ConfigurationException
      {
          m_logger.fatalError("configure");
          m_configuration = configuration;
      }
  
  
  }      
        </source>      
        <p><strong>Example TestCase (from Phoenix's own PUnit TestCase)</strong></p>
     
        <source>
  public class PUnitTestCaseTestCase extends PUnitTestCase
  {
  
      DefaultConfigurationBuilder m_defaultConfigurationBuilder = new DefaultConfigurationBuilder();
  
  
      public PUnitTestCaseTestCase(String name)
      {
          super(name);
      }
  
      public void testBasicBlock() throws Exception
      {
          TestBlock block = new TestBlock();
          Configuration configuration = m_defaultConfigurationBuilder.build(
                  new InputSource(new StringReader("&lt;hi&gt;Hi&lt;/hi&gt;")));
          addBlock("bl","block", block, configuration);
          startup();
          // check lifecycle run thru
          assertNotNull("Configuration null", block.m_configuration);
          assertNotNull("Context null", block.m_context);
          assertNotNull("Logger null", block.m_logger);
          assertNotNull("ServiceManager null", block.m_serviceManager);
          assertTrue("Not Initialized", block.m_initialized);
          // check lifecycle events logged
          assertTrue("Service Not logged", super.logHasEntry("I:service"));
          assertTrue("Initialize Not logged", super.logHasEntry("W:initialize"));
          assertTrue("Contextualize Not logged", super.logHasEntry("E:contextualize"));
          assertTrue("Configure Not logged", super.logHasEntry("F:configure"));
          shutdown();
      }
  
  }      
        </source>
        <p>
          What is shown here is a sinle block being manually instantiated, and registered
with PUnit 
          (addBlock).  Configuration rather than being from a file, is handed in from this
source 
          via DefaultConfigurationBuilder (see its other methods for more flexibility).  The
method 
          startup() is causing the components (one only in this case) to be started. After
the normal 
          asserts have been invoked, the shutdown() is appropriate to tidy up in time for
the next 
          test.  If you have multiple tests to do, it might be best to do all that is setup
and 
          tearDown methods.       
        </p>
        <p>
          It is important for developers to know the order of dependancy of their components,
and in
          fact, the dependency needs of all components used in the test.  This is normally
the role
          of the assembler rather than the developer, but there is no way that unit testing
can 
          occur without all component needs being satisfied.  Of course the developer can
use mock
          implementations of the required services.  Lastly, the order of dependency is important.
          Phoenix itself spends some effort determining which components are not needed by
anything
          and cycles them first during startup.  The last to be cycled are those that depend
on the
          others.
        </p>
      </section>
      <section><title>To Use</title>
        <p>
          When setting up a classpath, excalibur's containerkit and il8n jars are dependencies
for Punit...
        </p>
        <source>
    &lt;path id="test.class.path"&gt;
      &lt;pathelement location="build/testclasses"/&gt;
      &lt;path refid="compile.classpath"/&gt;
      &lt;pathelement location="lib/phoenix-punit.jar"/&gt;        
      &lt;pathelement location="lib/excalibur-containerkit-1.0.jar"/&gt;    
      &lt;pathelement location="lib/excalibur-i18n-1.0.jar"/&gt;
    &lt;/path&gt;     
        </source>
        <p>
          As with most testing frameworks, compilation of test classes is required before
tests can be invoked...
        </p>
        <source>      
       &lt;target name="test" depends="compile" description="compiles and runs unit tests"&gt;
   
           &lt;mkdir dir="build/testclasses"/&gt;
   
           &lt;javac 
               destdir="build/testclasses"
               debug="${build.debug}"
               optimize="${build.optimize}"
               deprecation="${build.deprecation}"&gt;
               &lt;classpath refid="test.class.path" /&gt;
               &lt;src path="src/test" /&gt;
           &lt;/javac&gt;
   
           &lt;mkdir dir="build/tests"/&gt;
   
           &lt;junit fork="true"
               haltonfailure="${junit.failonerror}"
               printsummary="yes"
               dir="build/tests"&gt;
               &lt;classpath refid="test.class.path"/&gt;
   
               &lt;formatter type="plain"/&gt;
   
               &lt;batchtest todir="build/tests"&gt;
                   &lt;fileset dir="build/testclasses"&gt;
                       &lt;include name="**/*TestCase.class"/&gt;
                       &lt;exclude name="**/Abstract*"/&gt;
                   &lt;/fileset&gt;
               &lt;/batchtest&gt;
           &lt;/junit&gt;
   
      &lt;/target&gt; 
        </source>    
      </section>
  
    </body>
  </document>
  
  
  

--
To unsubscribe, e-mail:   <mailto:avalon-cvs-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-cvs-help@jakarta.apache.org>


Mime
View raw message