[Cppunit-cvs] cppunit2/doc cppunit2todo.txt,1.1,1.2 features.txt,1.1,1.2

[Baptiste L. <bl...@us...>]

Update of /cvsroot/cppunit/cppunit2/doc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31427

Modified Files:
	cppunit2todo.txt features.txt 
Log Message:
* added a bit about functional testing

Index: cppunit2todo.txt
===================================================================
RCS file: /cvsroot/cppunit/cppunit2/doc/cppunit2todo.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** cppunit2todo.txt	15 Nov 2004 20:41:12 -0000	1.1
--- cppunit2todo.txt	16 Nov 2004 08:47:29 -0000	1.2
***************
*** 123,126 ****
--- 123,145 ----
  * call a specific function on the DLL passing remaining command-line parameter
  
+ Features to enhance
+ ===================
+ 
+ Equality check
+ --------------
+ 
+ At the current time it is impossible to overload the 
+ equality check on older compiler without 
+ function template ordering support such as VC++ 6 (you must specialize
+ the trait template)
+ 
+ The current implementation should be enhanced to detect if a 
+ specific overload is provided for comparison of AType and BType
+ is provided, and automatically fallback on the generic == otherwise.
+ This is similar to the convert to string trick used by stringize().
+ 
+ This would solve the overloading issue on older compiler without 
+ function template ordering support.
+ 
  ..
     Local Variables:

Index: features.txt
===================================================================
RCS file: /cvsroot/cppunit/cppunit2/doc/features.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** features.txt	15 Nov 2004 20:41:12 -0000	1.1
--- features.txt	16 Nov 2004 08:47:29 -0000	1.2
***************
*** 10,13 ****
--- 10,25 ----
  .. contents::
  
+ Support for unit testing and functional testing
+ ===============================================
+ 
+ The framework offers the traditional features found in unit testing framework
+ (assertions, grouping tests in suite...). A significant move has been made to 
+ provide more support for functional test:
+ 
+ * `rich test description`_
+ * `rich test result`_
+ * `non aborting assertions`_
+ * `test monitoring`_
+ 
  Supports for quick develop/test cycle
  =====================================
***************
*** 24,28 ****
  * test plug-in to reduce link-time on large project
  
! In a well-tuned environment that cycle can be as short as a few seconds,
  as you usually only recompile only two translation units (the test and
  the tested implementation), and run the test automatically after a 
--- 36,40 ----
  * test plug-in to reduce link-time on large project
  
! In a well-tuned environment the develop/test cycle can be as short as a few seconds,
  as you usually only recompile only two translation units (the test and
  the tested implementation), and run the test automatically after a 
***************
*** 37,44 ****
  specific dynamic library or of multiple dynamic libraries at once.
  
! Test-plug in also help separating the tests from how they are run, 
  thus allowing to centralize the way tests are run and their result
  reported.
  
  Test monitor to detect crash and infinite loop
  ==============================================
--- 49,58 ----
  specific dynamic library or of multiple dynamic libraries at once.
  
! Test-plug in also help separating the tests from the way they are run, 
  thus allowing to centralize the way tests are run and their result
  reported.
  
+ .. _`test monitoring`:
+ 
  Test monitor to detect crash and infinite loop
  ==============================================
***************
*** 51,62 ****
  test case.
  
  Graphical test driver
  =====================
  
! Graphical test driver are provided to:
  
  * navigate test hierarchy
  * run a specific test or test suite
  * browse test result
  
  Open test runner interface
--- 65,86 ----
  test case.
  
+ Test monitoring is provided by most test drivers of `Open Test`_.
+ 
+ Text test driver
+ =====================
+ 
+ A text test driver is provided by `Open Test`_ to. It is commonly used in a 
+ post-build step to run unit test with failure location in a compiler like 
+ format for integration with the development environment.
+ 
  Graphical test driver
  =====================
  
! Graphical test driver are provided by `Open Test`_ to:
  
  * navigate test hierarchy
  * run a specific test or test suite
  * browse test result
+ * and more...
  
  Open test runner interface
***************
*** 65,70 ****
  The test drivers (the components that run and monitor the tests) can work
  with any test runner that implements the `Open Test`_ interface. This
! means that the framework graphical test driver can be used to run and 
! monitor test implemented using another test framework as long as 
  the `Open Test`_ interface can be implemented for that other framework.
  
--- 89,94 ----
  The test drivers (the components that run and monitor the tests) can work
  with any test runner that implements the `Open Test`_ interface. This
! means that the framework text and graphical test drivers can be used to run and 
! monitor tests implemented using another test framework as long as 
  the `Open Test`_ interface can be implemented for that other framework.
  
***************
*** 97,100 ****
--- 121,138 ----
  parameters, and that default parameters are allowed.
  
+ One of the advantages of writing custom assertions is that in addition
+ to detecting that the assertion failed, a detailed diagnostic can be
+ provided. For example, when comparing two structured trees, 
+ knowing that they are different let you know that something is wrong, 
+ but not *what*. With custom assertions, the assertion can be tested, and
+ a detailed diagnostic based on the knowledge of what the structure
+ represent and what would be useful to diagnostic the failure can
+ be reported.
+ 
+ An application of advanced assertions can be found in 
+ `enumeration and string assertions`_.
+ 
+ (Notes: should move the detail below somewhere else.)
+ 
  Here is an example of how the assertion ``CPPUT_FAIL( "bad parameters." )`` 
  is expanded.
***************
*** 118,132 ****
  their number can vary.
  
! One of the advantages of writing custom assertions is that in addition
! to detecting that the assertion failed, a detailed diagnostic can be
! provided. For example, when comparing two structured trees, 
! knowing that they are different let you know that something is wrong, 
! but not *what*. With custom assertions, the assertion can be tested, and
! a detailed diagnostic based on the knowledge of what the structure
! represent and what would be useful to diagnostic the failure can
! be reported.
! 
! An application of advanced assertions can be found in 
! `enumeration and string assertions`_.
  
  Non aborting assertions support
--- 156,160 ----
  their number can vary.
  
! .. _`non aborting assertions`:
  
  Non aborting assertions support
***************
*** 143,147 ****
  checking assertions and vice versa.
  
! Property tree as test result for integration
  ============================================
  
--- 171,177 ----
  checking assertions and vice versa.
  
! .. _`rich test result`:
! 
! Test result as property tree for integration
  ============================================
  
***************
*** 165,170 ****
  actual values back into the spreadsheet.
  
! Property tree associated to each test declaration
! =================================================
  
  Each test has a property tree. The property tree can be used to store
--- 195,205 ----
  actual values back into the spreadsheet.
  
! Properties can be added to result result during the test case run. This
! makes it easy to provide rich structure output for functional testing.
! 
! .. _`rich test description`:
! 
! Test description as property tree
! =================================
  
  Each test has a property tree. The property tree can be used to store
***************
*** 210,218 ****
  automatically deferenced.
  
- [Notes: current implementation should be enhanced to detect if a 
- specific overload is provided for comparison of AType and BType
- is provided, and automatically fallback on the generic == otherwise.
- This is similar to the convert to string trick used by stringize().]
- 
  .. _`enumeration and string assertions`:
  
--- 245,248 ----
***************
*** 228,232 ****
  ----------------------------
  
! The enumeration based assertions works with the concept of enumerator.
  An enumerator implements a specific interface allowing enumeration
  of the elements of a collection. The CppTL library provides a complete
--- 258,262 ----
  ----------------------------
  
! The enumeration based assertions work with the concept of enumerator.
  An enumerator implements a specific interface allowing enumeration
  of the elements of a collection. The CppTL library provides a complete
***************
*** 258,262 ****
  * ensure a string contains another expected string.
  
! String assertions works with heterogeneous string type and use the
  stringize_ mechanism provided by the framework to convert object to string.
  
--- 288,292 ----
  * ensure a string contains another expected string.
  
! String assertions works with heterogeneous string types and use the
  stringize_ mechanism provided by the framework to convert object to string.