[Cppunit-devel] CppUnit 1.9.4 tar ball

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

    A much more mature test plug-in system that makes testable component a
reality. A lot of polishon many features.

    Notes that if the Unix side is fixed by the time of next public release,
the next public release might very well come with a broken unix build (there
is way to much new features to wait too long).

As usual:

http://cppunit.sourceforge.net/snapshot/
http://cppunit.sourceforge.net/snapshot/cppunit-1.9.4.tar.gz
http://cppunit.sourceforge.net/snapshot/cppunit-docs-1.9.4.tar.gz

 New in CppUnit 1.9.4:
 ----------------------

 - More versatile, easier to make test plug-in.
 - A PlugInManager to manage multiple test plug-ins.
 - Crossplatform test plug-in runner.
 - Crossplatform test plug-in example.
 - A brief progress listener
 - Easier test hierarchy creation
 - Improved documentation.
 - Tracking of test run start/end.
 - Contribution: XML style sheet & borland 5.5 makefile.
 - Help needed on the Unix side!

* Buildling on Unix:

  - I did not get any feed back on the previous build issue on Unix. Using
    a simple autobook example was useless to try to solve the problem. Here
 is the issue:

 CppUnit library build fine, it is the example I'm having trouble with.

 Since the test plug-in have been added, CppUnit use the function
 dlopen(), dlsym() and dlclose() on unix to load/unload the plug-in.

 Those functions apparently requires to link another library when
 building an exectuable. Here is was should be done:
 - linking against the said library for each example.
 - generates the shared library for the examples/simple/simple_plugin
   example (source files are ExampleTestCase.cpp, ExampleTestCase.cpp
   and SimplePlugIn.cpp).
 - if possible, makes the above optionnal if --disable-test-plug-in
   is defined:
   - don't link the dlXXX library
   - don't compile the plug-in example
   - add #define CPPUNIT_NO_TESTPLUGIN 1 to the config file

 Contact me on the mailing-list for more details.

* TestPlugIn:

  - A simple fact I realised while testing: if you link your test plug-in
    against the DLL version of cppunit (or shared library on Unix), then
 test registered to the TestFactoryRegistry (it is what's hide behind
 CPPUNIT_TEST_SUITE_REGISTRATION) are automatically shared. Changes
 have been made to support that usage (CppUnit was crashing badly).
 Using the TestFactoryRegistry provides much more flexiblity that
 providing a single suite for the plug-in. As such:

  - CppUnit plug-in should be linked against the dll version of CppUnit
library.

  - Plug-in should register their tests using the CPPUNIT_TEST_SUITE_xxx
macros.

  - 'homemade' suite can still be registred to the TestFactoryRegistry that
is
     passed as parameter on plug-in initialization. Notes that you must
  unregister those suites during plug-in uninitialization, otherwise on
  destruction, the TestFactoryRegistry will attempt to destroy them... Your
  plug-in would have been already unloaded...

  - Plug-in can accept parameters on initialization (notes that the
Parameters
    object is far from being stabilized, but whatever form it takes, it will
be
 a list of string).

  - Plug-in can register their one listener for a test run. This means that
you
    can extends 'DllPlugInTester' by creating test plug-in... This also
means
 than you can listen to startTestRun()/endTestRun() to do some global
 setUp/tearDown (to initialize globales resources, such as COM...)

  - Why all this fuss around test plug-in ? Test plug-in are the incarnation
of
    an old concept: testable components...

* PlugInManager:

  - The PlugInManager is used to load/unload plug-ins. It takes care of all
    the 'plug-in' protocol and makes it easy to use multiple plug-ins at the
 same time. It dispatches the addListener()/removeListener() message to
 each plug-in.

* Crossplatform test plug-in runner (src/DllPlugInRunner):

  - This application can be used to run your test plug-ins. It can load
    multiple test plug-ins and run all or a specific test in the test
 hierarchy returned by TestFactoryRegistry::getRegistry().makeTest().

  - Plug-in loaded by the plug-in may also be custom TestListener.

  - It can be use for post-build check and to debug the plug-in.

  - Why use it? It keep you away from CppUnit API changes!

* Easier test hierarchy creation (TestFactoryRegistry/HelperMacros):

  - added method addRegistry(name) to add a named registry to the registry.
    see TestFactoryRegistry for an example of use.

  - added macros CPPUNIT_REGISTRY_ADD( which, to ) and
    CPPUNIT_REGISTRY_ADD_TO_DEFAULT( which ) to create test hierarchy at
static
 initialization (in the spirit of CPPUNIT_TEST_SUITE_xxx() macros).

* VerboseTestProgressListener:

  - A new TestListener that prints the test name before running it. Most
useful when
    a test crashing, mean a application crash.

* Documentation:

  - More details about the test plug-in, how to use it, how does it works...
    See module/Writing Test Plug-in.

* Examples:

  - examAdded crossplatform simple example. Equivalent to VC++ HostApp
example.
  - examples/simple: a very simple example, demonstrating the use of CppUnit
    with a single TestFixture. Demonstrate both how to build an application
 using TestRunner, and how to build a test plug-in to use with the
 test plug-in runner.

* Contribution

  - Contributed by project cuppa team
(http://sourceforge.jp/projects/cuppa/):

 - XML style sheet: transform CppUnit XML output into HTML.
 - Makefile for CppUnit with Borland C++ 5.5 free compiler.

* Behavior changes:

  - Test runner should call TestResult::runTest() to run the 'top level'
test. This
    will inform the TestListener of the test run start/end.

* Compatiblity break:

  - TestFactoryRegistry don't own register test anymore. AutoRegisterSuite
has
    been updated to preverse its apparent behavior. It should be of concern
 if you created and registered custom TestFactory.

  - Removed TextTestProgressListener::done(). No longer needed, it listens
    for endTestRun().

* Compatiblity Break for 1.9.2 users:

  - TestPlugIn.h: CppUnitTestPlugIn as been completly rewritten.

  - TestPlugIn.h: macro CPPUNIT_PLUGIN_IMPLEMENT() don't take any arguments.

  - TestSuitePlugIn: removed. A similar functionnality is provided by
    PlugInManager.

  - TestPlugInDefaultImpl: renamed TestPlugInAdapter. It does not implements
    any default behavior anymore.

  - DllPlugInRunner: no longer support multiple specific tests. The test
path must
    be prefixed with ':'. Release and Debug configuration links against
cppunit_dll.

* Bug Fix:

  - Crash when linking CppUnit DLL within another DLL that registered test.
Caused
    by the destruction of tests registered to TestFactoryRegistry. Fixed by
 providing a register/unregister interface and removing the ownership of
 TestFactory to TestFactoryRegistry.

Enjoy,
Baptiste.
---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/