diff --git a/bazaar/UnitTest++/srcdoc.tpp/UnitTestpp$en-us.tpp b/bazaar/UnitTest++/srcdoc.tpp/UnitTestpp$en-us.tpp
index f77b05f1b..9bda774a8 100644
--- a/bazaar/UnitTest++/srcdoc.tpp/UnitTestpp$en-us.tpp
+++ b/bazaar/UnitTest++/srcdoc.tpp/UnitTestpp$en-us.tpp
@@ -54,7 +54,8 @@ how the library can be used.&]
 [s5; The U`+`+ version of UnitTest`+`+ comes with UnitTestTest package, 
 which is a full test suite using UnitTest`+`+. This is a great 
 place to learn techniques for testing. There is one sample .cpp 
-file: [C UnitTestTest/TestUnitTest`+`+.cpp]. It covers most of UnitTest`+`+`'s 
+file: [C^http`:`/`/code`.google`.com`/p`/upp`-mirror`/source`/browse`/trunk`/bazaar`/UnitTestTest`/TestUnitTest`%2B`%2B`.cpp^ U
+nitTestTest/TestUnitTest`+`+.cpp]. It covers most of UnitTest`+`+`'s 
 features in an easy`-to`-grasp context, so start there if you 
 want a quick overview of typical usage.&]
 [s22; Getting started&]
@@ -322,4 +323,99 @@ or another, it will be handled by UnitTest`+`+.&]
 step, so that merely building your test project will run the 
 tests as well. Since the exit code is the count of failures, 
 a failed test will generally break the build, as most build engines 
-will fail a build if any step returns a non`-zero exit code.]
\ No newline at end of file
+will fail a build if any step returns a non`-zero exit code.&]
+[s0; &]
+[s3; Best practices to use UnitTest`+`+ together with U`+`+&]
+[s5; For a complex modular application using several packages as 
+modules, I`'m following these patterns.&]
+[s22; Packages organization&]
+[s0; Each production package (module) has `"test`" package counterpart, 
+for example with package [C MainAccounting] I do create package 
+[C MainAccountingTests] as well. The test package contains at least 
+one cpp file, for example:&]
+[s7; //MainAccountingTests.cpp&]
+[s7; #include <MainAccounting/MainAccounting.h>-|//MainAccounting 
+package API definition&]
+[s7; #include <UnitTest`+`+/UnitTest`+`+.h>&]
+[s7; &]
+[s7; void MainAccountingTestsCPP() `{`}-|//linking hack, each new 
+CPP test file has it&]
+[s7; &]
+[s7; SUITE(MainAccounting`_tests) `{&]
+[s7; -|TEST(MainAccounting`_Instantiate) `{&]
+[s7; -|-|MainAccounting macc;&]
+[s7; -|`}&]
+[s7; `}&]
+[s0; The test package also does add UnitTest`+`+ package from bazaar, 
+and original MainAccounting package, and ideally nothing else. 
+Because other non test packages should be already added in MainAccounting 
+package.&]
+[s0; &]
+[s0; Then I do have a ProjectTestsAll package, where I add all the 
+module`-test packages, Core package and UnitTest`+`+ package. 
+This package contains ordinary console application [C main]:&]
+[s7; //ProjectTestsAll.cpp&]
+[s7; #include <Core/Core.h>&]
+[s7; #include <UnitTest`+`+/UnitTest`+`+.h>&]
+[s7; #define RUN`_IN`_RELEASE(x) extern void x(); x()&]
+[s7; &]
+[s7; CONSOLE`_APP`_MAIN&]
+[s7; `{&]
+[s7; -|//HACK: force all CPP files with tests to link and run tests 
+in Release compilation mode.&]
+[s7; -|RUN`_IN`_RELEASE( MainAccountingTestsCPP );&]
+[s7; &]
+[s7; -|UPP`::SetExitCode( UnitTest`::RunAllTests() );&]
+[s7; `}&]
+[s0; &]
+[s0; There`'s a dummy empty function in each [C tests.cpp] file, because 
+otherwise the tests are lost in release mode linking (in debug 
+mode it works without the hack).&]
+[s0; &]
+[s22; Where is the main&]
+[s0; The `"[C main]`" running tests is in the above mentioned piece 
+of code, in ProjectTestsAll package. What about the main of the 
+application itself?&]
+[s0; &]
+[s0; If you can have a single `"ProjectApp`" package adding all other 
+modules (packages) and containing just a bare minimum of code 
+to run the app, then by omitting this package from TestsAll you 
+avoid any linking conflicts with multiple main entry points.&]
+[s0; &]
+[s0; If your main package is larger, and does contain also functions 
+you want to test, you should add a `"[C UNITTEST]`" flag into main 
+configuration of TestsAll package (Project/Main package configuration, 
+edit the main line, or add first if none exists), then in the 
+main package enclose the real application `"main`" inside [C #ifndef 
+flagUNITTEST] / [C #endif] directives, and add also main package 
+to TestsAll.&]
+[s0; &]
+[s0; This way you select the ProjectTestsAll package while doing 
+TDD (test driven development) or when you want to run tests, 
+hit run and the tests are failing (or running). Once you are 
+satisfied with all tests and you want to run actual application, 
+switch to main Project package containing the real main, and 
+run it.&]
+[s0; &]
+[s22; Other remarks&]
+[s0; Don`'t forget to run tests in all possible compiler configurations, 
+which should be supported. I.e. both release and debug mode, 
+and in case you use more compilers (MSCC vs GCC/MINGW), use both 
+also to run tests. At least once per couple of days, but I think 
+doing this daily is the right way (or having continuous integration 
+server doing automated builds all the time). This will give you 
+chance to catch subtle incompatibilities very early, and it will 
+often help to discover nasty bugs which are hiding in particular 
+mode/compiler combination, and will be revealed only in different 
+combination.&]
+[s0; &]
+[s22; GUI testing&]
+[s0; I`'m sorry if you find this too much `"console`" oriented: I 
+didn`'t personally need to test any GUI parts of application 
+(a mix of GUI main package solving layout and GUI functions `+ 
+independent module doing the internals did solve this for me 
+sufficiently), and so far I`'m not sure even where to start with 
+GUI testing.&]
+[s0; &]
+[s0; This area is open for anyone who want to improve U`+`+ tools 
+and has some great ideas.]
\ No newline at end of file