github-starred/ultimatepp
2
0
Fork 0
mirror of https://github.com/ultimatepp/ultimatepp.git synced 2026-07-11 22:03:01 -06:00
Code Issues 33 Projects Packages Wiki Activity Actions

UnitTest++: docs improved (best practices under U++)

Browse source 
git-svn-id: svn://ultimatepp.org/upp/trunk@1954 f0d560ea-af0d-0410-9eb7-867de7ffcac7
This commit is contained in:
mr_ped 2010-01-26 12:06:00 +00:00
parent 3c7d7065ae
commit a20616db85
1 changed files with 98 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

100
bazaar/UnitTest++/srcdoc.tpp/UnitTestpp$en-us.tpp
View file

@ -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.]
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.]