diff -r 1788e52b3086 -r fca9099ab398 doc/testing.txt
--- a/doc/testing.txt	Tue Apr 07 05:51:44 2015 -0700
+++ b/doc/testing.txt	Thu Apr 09 18:28:09 2015 -0700
@@ -9,7 +9,8 @@
 'gmake test' is often run when a component is upgraded or otherwise
 intentionally changed, but sometimes it would be useful to rerun the tests
 after something else has changed (such as the system being upgraded, or a
-change in compilers) and see if that has affected the tests.
+change in compilers; see the 'System Test' section below) and see if that
+has affected the tests.
 
 We do this by having a 'master test file' that contains the expected results,
 and having a compare target that runs the tests and compares them with the
@@ -208,3 +209,53 @@
 
 When your master test file(s) are in good shape, then you should "hg add"
 them to your workspace.
+
+
+System Test
+-----------
+All of the above discusses how 'gmake test' works.  This is all good, but
+has the limitation that objects under test are those that were just built
+and installed into the component's proto area.  We also want to be able
+to test whatever is installed on the actual system.  This has the benefits
+of not requiring anything to be built, and allowing non-Userland people
+to test our bits.  (Think of people in ON changing libc or the linker and
+wanting to make sure they don't break anything.)
+
+To this end, we have added 'gmake system-test'.  It works just like 'gmake
+test', reusing some of the same variables:
+* COMPONENT_TEST_BUILD_DIR
+* COMPONENT_TEST_COMPARE
+* COMPONENT_TEST_CREATE_TRANSFORMS
+* COMPONENT_TEST_OUTPUT
+* COMPONENT_TEST_PERFORM_TRANSFORM
+but with its own "_SYSTEM" instance of other variables:
+* COMPONENT_POST_SYSTEM_TEST_ACTION
+* COMPONENT_PRE_SYSTEM_TEST_ACTION
+* COMPONENT_SYSTEM_TEST_ARGS
+* COMPONENT_SYSTEM_TEST_CLEANUP
+* COMPONENT_SYSTEM_TEST_CMD
+* COMPONENT_SYSTEM_TEST_DIR
+* COMPONENT_SYSTEM_TEST_ENV
+* COMPONENT_SYSTEM_TEST_ENV_CMD
+* COMPONENT_SYSTEM_TEST_RESULTS_DIR
+* COMPONENT_SYSTEM_TEST_TARGETS
+
+In the ideal case, only Makefile variables would need to be modified to
+take a component where 'gmake test' works and extend it so that 'gmake
+system-test' works; see components/python34/Makefile for such an example.
+
+The next level up from that is the case where some simple patching is needed.
+In this case, simple means:
+* tweaking LD_LIBRARY_PATH
+* changing the path to a binary to run
+* modifying a Makefile so tests are compiled as part of 'gmake build'
+* modifying a Makefile so tests are installed as part of 'gmake install'
+* modifying a pkg(5) manifest so tests are published as part of 'gmake publish'
+  (preferably under the "optional.test" facet)
+
+If more extensive patching is needed, a judgement call needs to be made:
+Are these changes that upstream would welcome?  If not, then we would need
+to keep such changes around indefinitely, which would constitute a fork,
+which we try very hard to avoid.  When 'gmake system-test' was initially
+implemented, changes to both fetchmail and python/decorator were begun but
+ultimately abandoned for this reason; see 20808505 for details.