X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/670ec357654cdee164e8ade5f6b7852f3108fa26..d841895246c188d722bae08e9f37c7270bc56ea8:/docs/tech/tn0017.txt

diff --git a/docs/tech/tn0017.txt b/docs/tech/tn0017.txt
index 327ce2e703..2ba859990c 100644
--- a/docs/tech/tn0017.txt
+++ b/docs/tech/tn0017.txt
@@ -1,7 +1,7 @@
-                    How to write unit tests for wxWindows
+                    How to write unit tests for wxWidgets
                     =====================================
 
- Unit tests for wxWindows are written using small cppunit framework. To compile
+ Unit tests for wxWidgets are written using small cppunit framework. To compile
 (but not to run) them you need to have it installed. Hence the first part of
 this note explains how to do it while the second one explains how to write the
 test.
@@ -50,8 +50,8 @@ III. Running the tests
 ----------------------
 
 1. Regenerate the make/project files from test.bkl using bakefile_gen, e.g.:
-        cd build/bakefile
-        bakefile_gen ../../tests/test.bkl
+        cd build/bakefiles
+        bakefile_gen -b ../../tests/test.bkl
    and if you're on a unix system re-run configure.
 
 2. Build the test program using one of the make/project files in the tests
@@ -59,7 +59,7 @@ III. Running the tests
 
 3. Run the test program with no arguments to run the default set of tests
    (which are all those registered with CPPUNIT_TEST_SUITE_REGISTRATION).
-   Or to list the tests without running them:
+   Or to list the test suites without running them:
       test -l
 
 4. Tests that have been registered under a name using
@@ -67,7 +67,7 @@ III. Running the tests
    example:
       test MBConvTestCase
    or to list the tests:
-      test -l MBConvTestCase
+      test -L MBConvTestCase
 
 
 IV. Notes
@@ -76,11 +76,26 @@ IV. Notes
 1. You can register your tests (or a subset of them) just under a name, and not
    in the unnamed registry if you don't want them to be executed by default.
 
-2. If you are going to register your tests both in the unnamed registry and
-   under a name, then use the name that the tests have in the 'test -l'
-   listing (which is often the name of the TestCase class). Then the top
-   level names in a 'test -l' listing can be a hint as to the name those
-   tests have been registered under.
+2. If you are going to register your tests both in the unnamed registry
+   and under a name, then use the name that the tests have in the 'test -l'
+   listing.
+
+3. Tests which fail can be temporarily registered under "fixme" while the
+   problems they expose are fixed, instead of the unnamed registry. That
+   way they can easily be run, but they do not make regression testing with
+   the default suite more difficult. E.g.:
+
+    // register in the unnamed registry so that these tests are run by default
+    //CPPUNIT_TEST_SUITE_REGISTRATION(wxRegExTestCase);
+    CPPUNIT_TEST_SUITE_NAMED_REGISTRATION(wxRegExTestCase, "fixme");
+
+    // also include in it's own registry so that these tests can be run alone
+    CPPUNIT_TEST_SUITE_NAMED_REGISTRATION(wxRegExTestCase, "wxRegExTestCase");
+
+4. Tests which take a long time to execute can be registered under "advanced"
+   instead of the unnamed registry. The default suite should execute reasonably
+   quickly. To run the default and advanced tests together:
+    test "" advanced
 
 
 === EOF ===