package-info.java

MoMEUnit是一个单元测试的J2ME的应用程序xUnit架构实例。这是来自JUnit框架

/**
 * <P>
 * MoMEUnit is an instance of the xUnit architecture for unit testing of J2ME
 * applications. It is derived from JUnit framework. <STRONG>It is only CLDC 1.1
 * complied</STRONG>.
 * </P>
 * <H3>Overview</H3>
 * <P>
 * The main problem of using JUnit frameork in development of J2ME applications
 * is a lack of reflection API in MIDP API. So it is impossible to keep implicit
 * association between the test method name and name of test case. In my humble
 * option, if it is not possible, we shouldn't do this. This framework doesn't
 * make use of <CODE>test&lt;TestName&gt;</CODE> method signature. It
 * introduces only one test method:
 * </P>
 * 
 * <PRE>
 * 
 * public void test() throws Throwable
 * 
 * </PRE>
 * 
 * <P>
 * Different tests can be created by different subclasses of
 * {@link momeunit.framework.TestCase} class. Sharing of the same fixture
 * between different tests is realized via subclassing. One approach is to
 * create one subclass of {@link momeunit.framework.TestCase} by overriding
 * {@link momeunit.framework.TestCase#test()} method and fixture methods and
 * defining instance variables to store the state of the fixture. Other tests
 * will extend this test sharing the same fixture. It is of course possible to
 * override fixture methods (e.g. to add additional functionality) and add other
 * instance variables if needed. Another more general approach is to create
 * abstract {@link momeunit.framework.TestCase} subclass overriding
 * {@link momeunit.framework.TestCase#setUp()} and/or
 * {@link momeunit.framework.TestCase#tearDown()} methods, defining instance
 * variables to store the state of the fixture. All test cases will extend this
 * abstract class (But, to my mind, this is just a waste of time and memory). In
 * both cases we can keep implicit association between name of
 * {@link momeunit.framework.TestCase} subclass and name of test case. In this
 * framework the default test case name is name of
 * {@link momeunit.framework.TestCase} subclass without 'packages' prefix (e.g.
 * for class &quot;com.foo.bar.AbcTest&quot; the name of test case will be
 * &quot;AbcTest&quot;). Each test runs in its own fixture of course. So there
 * are no side effects concerning test runs.
 * </P>
 * <P>
 * The other minor changes to the JUnit framework are the absence of
 * <code>ComparisonFailure</code> class and modification to
 * <code>TestResult</code>, <code>TestFailure</code> classses. The only
 * function of <code>ComparisonFailure</code> class is just processing of
 * strings to show only different parts of them in the assertion message. To my
 * mind such a class is redundant in J2ME test framework. Of course this
 * functionality is useful especially taking into consideration limited
 * characteristics of display of devices. So it is putted in respective
 * assertEquals methods of {@link  momeunit.framework.Assert} class. In this
 * framework {@link  momeunit.framework.TestResult} class contains only one
 * registered {@link  momeunit.framework.TestListener} instead of collection. To
 * my mind one listener is definitely enough in J2ME testing framework. To use a
 * collection of registered TestListeners create
 * {@link  momeunit.framework.TestListener} implementation that contains a
 * collection of test listeners and propagates test events to them. It is also
 * impossible to get stack-trace of thrown exception as a String. So TestFailure
 * method {@link momeunit.framework.TestFailure#printTrace()} only prints it to
 * the standard error output. This is the only possible way to get it.
 * </P>
 * 
 * <h3>Creating Tests</h3>
 * <p>
 * Creating of tests is pretty simple I shortly described this above. Create a
 * TestCase subclass by defining instance variables to store the state of the
 * fixture, overriding {@link momeunit.framework.TestCase#setUp()} method to set
 * this variables, and/or overriding
 * {@link momeunit.framework.TestCase#tearDown()} method to clean up after test
 * execution, implementing {@link momeunit.framework.TestCase#test()} method to
 * perform test and assert the results. For example traditional AddTest:
 * </p>
 * 
 * <pre>
 * public class AddTest extends TestCase
 * {
 *   protected int arg1;
 * 
 *   protected int arg2;
 * 
 *   protected void setUp()
 *   {
 *     this.arg1 = 2;
 *     this.arg2 = 5;
 *   }
 * 
 *   public void test()
 *   {
 *     int res = arg1 + arg2;
 *     assertEqual(&quot;I don't know what happened&quot;, 7, res);
 *   }
 * }
 * </pre>
 * 
 * <p>
 * To create another test that shares the same fixture just subclass this class.
 * For example traditional SubtractTest:
 * </p>
 * 
 * <pre>
 * public class SubtractTest extends AddTest
 * {
 *   public void test()
 *   {
 *     int res = arg2 - arg1;
 *     assertEqual(&quot;I again don't know what happened&quot;, 2, res);
 *   }
 * }
 * </pre>
 * 
 * <p>
 * Each test runs in its own fixture. So there are no side effects concerning
 * test runs.
 * </p>
 * <h3>Running tests</h3>
 * <p>
 * Tests can be executed by using any test runner. This framework provides as an
 * extension a <em>MIDletTestRunner</em> - a fully configurable MIDlet. It
 * runs tests in emulator (e.g. WTK emulator) and shows the results (progress
 * bar, statistics, lists of failures or errors with detailed messages) in one
 * screen. In my humble option pretty good test runner for J2ME applications.
 * </p>
 * <P>
 * It is, of course, possible to run test case or hierarchy of test cases
 * without test runner.
 * </P>
 * <p>
 * To run a specific test case and obtain results just call
 * {@link momeunit.framework.TestCase#run()} method. For example:
 * </p>
 * 
 * <pre>
 * result = new Addtest().run()
 * </pre>
 * 
 * <p>
 * To run a bunch of test cases use a {@link momeunit.framework.TestSuite}
 * class. Instantiate it by calling a constructor that takes array of classes or
 * array of strings as arguments with array of classes or names of classes
 * implementing {@link momeunit.framework.Test} interface and call
 * {@link momeunit.framework.TestSuite#run( momeunit.framework.TestResult )}
 * method.
 * </p>
 * 
 * <pre>
 * TestSuite suite = new TestSuite(&quot;ArithmeticTest&quot;, new Class[] { AddTest.class,
 *     SubtractTest.class });
 * // TestSuite suite = new TestSuite(&quot;ArithmeticTest&quot;, new String[] { &quot;AddTest&quot;, &quot;SubtractTest&quot; });
 * TestResult res = new TestResult();
 * suite.run(res);
 * </pre>
 * 
 * <p>
 * It is possible of course to add other tests to test suite after creation of
 * test suite by calling {@link momeunit.framework.TestSuite#addTest( Class )}
 * or {@link momeunit.framework.TestSuite#addTest( String )} methods with class
 * or name of class implementing {@link momeunit.framework.Test} interface or
 * calling
 * {@link momeunit.framework.TestSuite#addTest( momeunit.framework.Test )}
 * method with Test instance.
 * </p>
 * 
 * @author Sergio Morozov
 * @version 1.1.2
 */
package momeunit.framework;