[Mockpp-commits] mockpp/mockpp/docs/en appendix.docbook,1.13,1.14 bookinfo.docbook,1.9,1.10 dev_adva
Brought to you by:
ewald-arnold
Menu
▾
▴
[Mockpp-commits] mockpp/mockpp/docs/en appendix.docbook,1.13,1.14 bookinfo.docbook,1.9,1.10 dev_advanced_intro.docbook,1.9,1.10 dev_advanced_jmock.docbook,1.17,1.18 dev_basic.docbook,1.13,1.14 dev_embedded.docbook,1.8,1.9 dev_helper.docbook,1.10,1.11 dev_intro.docbook,1.6,1.7 dev_poor_mans_mock.docbook,1.6,1.7 dev_production.docbook,1.5,1.6 dev_test_framework.docbook,1.2,1.3 faq.docbook,1.10,1.11
|
From: Ewald A. <ewa...@us...> - 2005-12-27 18:01:56
|
Update of /cvsroot/mockpp/mockpp/mockpp/docs/en In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4794/mockpp/docs/en Modified Files: appendix.docbook bookinfo.docbook dev_advanced_intro.docbook dev_advanced_jmock.docbook dev_basic.docbook dev_embedded.docbook dev_helper.docbook dev_intro.docbook dev_poor_mans_mock.docbook dev_production.docbook dev_test_framework.docbook faq.docbook Log Message: spell check Index: dev_poor_mans_mock.docbook =================================================================== RCS file: /cvsroot/mockpp/mockpp/mockpp/docs/en/dev_poor_mans_mock.docbook,v retrieving revision 1.6 retrieving revision 1.7 diff -u -d -r1.6 -r1.7 --- dev_poor_mans_mock.docbook 19 Feb 2005 17:57:52 -0000 1.6 +++ dev_poor_mans_mock.docbook 27 Dec 2005 18:01:44 -0000 1.7 @@ -9,7 +9,7 @@ <para>I hate a bit to mention but most of the time you don't need a full blown mock object libray. Often a more or less quick and dirty approach suffices if you do the right thing. In such cases I don't care too much about correct access -restrictions or hiding variables behind methods. Tests usally lie in the lower +restrictions or hiding variables behind methods. Tests usually lie in the lower areas of your project tree and nobody should try to re-use a test object in production code. So a more pragmatic approach won't hurt your project. But if you prefer you can of course do it the clean way.</para> Index: dev_embedded.docbook =================================================================== RCS file: /cvsroot/mockpp/mockpp/mockpp/docs/en/dev_embedded.docbook,v retrieving revision 1.8 retrieving revision 1.9 diff -u -d -r1.8 -r1.9 --- dev_embedded.docbook 24 Dec 2005 01:40:06 -0000 1.8 +++ dev_embedded.docbook 27 Dec 2005 18:01:44 -0000 1.9 @@ -5,9 +5,9 @@ <title>The Problem</title> <para>There are hidden costs concerning memory resources when programming in -C++. On a desktop system with plenty of virtual memory you don't neccessarily -recognize it. But working with embedded systems is different as there is only a -limited amout of physical memory available.</para> +C++. On a desktop system with plenty of virtual memory you don't necessarily +recognise it. But working with embedded systems is different as there is only a +limited amount of physical memory available.</para> <para>For that reasons it is important to know the places where he compiler adds additional code: @@ -87,10 +87,10 @@ miss the one or the other feature current implementations have. Either you find a workaround for this or you implement what is missing. There are also STL implementations -available which are optimzied for embedded systems.</para> +available which are optimised for embedded systems.</para> <para>The only real problem is exception handling. You can't simply turn his -feature off and continue with the programm flow instead of throwing. When +feature off and continue with the program flow instead of throwing. When throwing an exception an application is typically in a critical state and its objects tend to be unusable. Continuing to use such an object is likely to crash the application. The other problem is the @@ -102,7 +102,7 @@ the thread upon the first malfunction. Probably this significantly slows down the test execution. Another possibility is to split the tests into portable and platform specific sections. The portable sections can be run on the development -machine with high speed very often wherereas the complete tests are run on the +machine with high speed very often whereas the complete tests are run on the target device only if appropriate.</para> <para>Without exceptions you have to provide a way to forward the messages @@ -134,14 +134,17 @@ <caution>Please note that the macro is located in source (*.cpp) files as well as in header files. So changing the macro between different test files or projects might not work -as expected. It is inteded as immutable glue between &mockpp; and your favourite +as expected. It is intended as immutable glue between &mockpp; and your favourite unittest framework.</caution> To relax this constraint there is a mutable function pointer which can be changed at runtime to actually process the exception data. All internal assertions use -this approch. The default is to throw an exception. But by calling +this approach. The default is to throw an exception. But by calling <function>setAssertionFailedForwarder()</function> appropriately it is possible -to print a message to the screen and exit the application. +to print a message to the screen and exit the application. Alternatively you may +as well call the according collector of your unittest framework. E.g. +<methodname>CPPUNIT_FAIL</methodname> for &cppunit; or +<methodname>TS_FAIL</methodname> for &cxxtest;. <programlisting> @@ -154,7 +157,7 @@ inline void printMalfunctionData(const T & /* dummy fallback */) { - std::cout << "unknown exception occured" << std::endl; + std::cout << "unknown exception occurred" << std::end; exit(1); } @@ -162,7 +165,7 @@ inline void printMalfunctionData(const mockpp::AssertionFailedError &e) { - std::cout << e.getMessage() << std::endl; + std::cout << e.getMessage() << std::end; exit(1); } @@ -170,7 +173,7 @@ inline void printMalfunctionData(const std::exception &e) { - std::cout << e.what() << std::endl; + std::cout << e.what() << std::end; exit(1); } Index: bookinfo.docbook =================================================================== RCS file: /cvsroot/mockpp/mockpp/mockpp/docs/en/bookinfo.docbook,v retrieving revision 1.9 retrieving revision 1.10 diff -u -d -r1.9 -r1.10 --- bookinfo.docbook 15 Nov 2005 19:19:25 -0000 1.9 +++ bookinfo.docbook 27 Dec 2005 18:01:44 -0000 1.10 @@ -36,8 +36,8 @@ and <ulink url="http://www.jmock.org/">jMock</ulink>. </para> -<para>Mock objects allow you to set up exactly predictible -behaviour to help you test your production code by emulating some functionalitiy your code depends on. +<para>Mock objects allow you to set up exactly predictable +behaviour to help you test your production code by emulating some functionality your code depends on. This might for example be a huge database which is too difficult and time consuming to maintain just for testing purposes.</para> Index: appendix.docbook =================================================================== RCS file: /cvsroot/mockpp/mockpp/mockpp/docs/en/appendix.docbook,v retrieving revision 1.13 retrieving revision 1.14 diff -u -d -r1.13 -r1.14 --- appendix.docbook 2 Dec 2005 17:28:36 -0000 1.13 +++ appendix.docbook 27 Dec 2005 18:01:44 -0000 1.14 @@ -70,7 +70,7 @@ </varlistentry> <varlistentry> - <term>--disable-rtti</term> + <term>--disable-RTTI</term> <listitem>Some environments don't use runtime type information to reduce the size of the footprint of the binaries. In this case the according debugging information is omitted. @@ -86,7 +86,7 @@ </varlistentry> <varlistentry> - <term>--enable-builtin-stl</term> + <term>--enable-builtin-STL</term> <listitem>By default &mockpp; is compiled with the C++ Standard Template Libray that comes with your compiler. Unfortunately the current implementations consume rather much resources. For that reason a built-in minimalistic STL can be used. @@ -116,7 +116,7 @@ <sect2 id="creating-rpms"> <title>Creating and Installing an RPM</title> -<para>Using the previous installation procedure has drawacks when you +<para>Using the previous installation procedure has drawbacks when you want do uninstall or upgrade to a newer version. Maybe you rather want to benefit from the common mechanism provided by <application>rpm</application>. Before installing the library this way you need to create rpm packages @@ -133,7 +133,7 @@ After completion you will receive two rpm packages: one for the library and the headers and one for the documentation. They are usually located at -<filename>/usr/src/pacakges/RPMS</filename>. +<filename>/usr/src/packages/RPMS</filename>. </para> </sect2> Index: dev_test_framework.docbook =================================================================== RCS file: /cvsroot/mockpp/mockpp/mockpp/docs/en/dev_test_framework.docbook,v retrieving revision 1.2 retrieving revision 1.3 diff -u -d -r1.2 -r1.3 --- dev_test_framework.docbook 21 Dec 2005 20:05:40 -0000 1.2 +++ dev_test_framework.docbook 27 Dec 2005 18:01:44 -0000 1.3 @@ -52,7 +52,7 @@ <para>The original working method of &cxxtest; is different to &cppunit;. A perl script searches the test sources and creates an additional source file which -is then call ompiled and run. All the library source files are directly included +is then call compiled and run. All the library source files are directly included into the main source file which means that you do not need to create a binary library for &cxxtest;.</para> @@ -64,7 +64,7 @@ &cxxtest; included in &mockpp; comes as binary library which should help to save some memory and download time which is important on embedded platforms.</para> -<para>&cxxtest; does netiher need RTTI nor exceptions to work. But it is possible +<para>&cxxtest; does neither need RTTI nor exceptions to work. But it is possible to check exception conditions.</para> <para>Similar to &cppunit; the test methods are invoked in unspecified order.</para> Index: dev_intro.docbook =================================================================== RCS file: /cvsroot/mockpp/mockpp/mockpp/docs/en/dev_intro.docbook,v retrieving revision 1.6 retrieving revision 1.7 diff -u -d -r1.6 -r1.7 --- dev_intro.docbook 21 Nov 2004 19:32:39 -0000 1.6 +++ dev_intro.docbook 27 Dec 2005 18:01:44 -0000 1.7 @@ -1,7 +1,7 @@ <sect1 id="devel-intro"> <title>Introduction</title> -<para>The following developer's guide is to get you started and to +<para>The following developer's guide is to get you started and to give you a quick overview over the features of &mockpp;. For a complete list of all functions please refer to the api documentation.</para> @@ -9,34 +9,34 @@ <itemizedlist> <listitem><para>&mockpp; uses a data type <token>String</token> which is no data type of it's own - but is a typdef to std::string or std::wstring depending on your choice. - It also provides a minumum functionality for unicode if you compile for + but is a typedef to std::string or std::wstring depending on your choice. + It also provides a mminimumfunctionality for unicode if you compile for a unicode environment. See <xref linkend="compilation" /> how to do that.</para> - - <para>Since &mockpp; provides both environments with the same sources it uses some - macros to convert string literals to the intended environment. You can check for + + <para>Since &mockpp; provides both environments with the same sources it uses some + macros to convert string literals to the intended environment. You can check for the actual setting by adding a conditional <literal>#ifdef MOCKPP_UNICODE</literal> in your sources.</para> - + <itemizedlist> <listitem><literal>MOCKPP_PCHAR</literal> transforms a literal string either to a <token>char*</token> or to a <token>wchar_t *</token> by prepending an <token>L</token> for unicode. </listitem> - + <listitem>In the same manner <literal>MOCKPP_STRING</literal> yields either a <token>std::string</token> or a <token>std::wstring</token>. </listitem> </itemizedlist> - + </listitem> - + <listitem>&mockpp; has no testing framework of it's own so it is recommended to use <ulink url="http://cppunit.sf.net">CppUnit</ulink> for that purpose. See the test and example files how to do it. </listitem> - + </itemizedlist> </para> Index: dev_basic.docbook =================================================================== RCS file: /cvsroot/mockpp/mockpp/mockpp/docs/en/dev_basic.docbook,v retrieving revision 1.13 retrieving revision 1.14 diff -u -d -r1.13 -r1.14 --- dev_basic.docbook 2 Dec 2005 17:28:36 -0000 1.13 +++ dev_basic.docbook 27 Dec 2005 18:01:44 -0000 1.14 @@ -35,7 +35,7 @@ <varlistentry> <term><methodname>setExpectNothing()</methodname></term> - <listitem>If you want to prevent the occurance of any actual values + <listitem>If you want to prevent the occurrence of any actual values you should invoke this method at the beginning. <note><title>Attention</title> @@ -59,7 +59,7 @@ <para> The most common application is the use of <classname>ExpectationValue</classname> -which does an exact comparision. Your own data types should implement a meaningful +which does an exact comparison. Your own data types should implement a meaningful <methodname>operator==()</methodname> to be usable with &mockpp;. Depending on your type <methodname>operator<()</methodname> can replace the formar operator by supplying a template which does the following @@ -89,7 +89,7 @@ Sometimes you have not only a single value but a series of values. For this purpose you set up a list of expectations of the same type. The next example creates an expectation list for <token>int</token> values. The list members are compared with the -actaul values one after the other in exactly the same order they were inserted. +actual values one after the other in exactly the same order they were inserted. <programlisting> @@ -179,7 +179,7 @@ <calloutlist> <callout arearefs="expset-co" id="expset" > - <para>Adding the same actual value more than once is ok for the set.</para> + <para>Adding the same actual value more than once is OK for the set.</para> </callout> </calloutlist> Index: faq.docbook =================================================================== RCS file: /cvsroot/mockpp/mockpp/mockpp/docs/en/faq.docbook,v retrieving revision 1.10 retrieving revision 1.11 diff -u -d -r1.10 -r1.11 --- faq.docbook 2 Dec 2005 17:28:36 -0000 1.10 +++ faq.docbook 27 Dec 2005 18:01:44 -0000 1.11 @@ -64,7 +64,7 @@ <para>A flexible and clean approach is the one used within mockpp: <itemizedlist> - <listitem>Place all the classes and funcions of your production code into + <listitem>Place all the classes and functions of your production code into appropriate libraries. All the source code for the according library is in a separate subdirectory.</listitem> @@ -74,7 +74,7 @@ <listitem>Create a subdirectory <filename>tests</filename> within each sub-project which contains all the test files needed. Depending on your test framework - the test files form a libary or an executable. Upon execution the above libray + the test files form a library or an executable. Upon execution the above libray with the production code is linked dynamically.</listitem> </itemizedlist> @@ -108,7 +108,7 @@ </question> <answer> - <para>The two reasons to use this aproach were enhanced readability and + <para>The two reasons to use this approach were enhanced readability and better support for internationalisation:</para> <para>Simply take the example from the handbook: @@ -151,12 +151,12 @@ << three; </programlisting> - I am pretty sure you will forget the one or the other space which seperates + I am pretty sure you will forget the one or the other space which separates for example the literal "plus" from the variable "two".</para> <para>The other important point is: you can't translate the second solution reasonably. - Translating "says:" and "plus" seperately and concatenating them like above often + Translating "says:" and "plus" separately and concatenating them like above often results in the nonsense you get when you read manuals for devices from the far east. Often also the order of the substituted words change in the translated version. In this case the translator simply would swap <token>%1</token> Index: dev_advanced_jmock.docbook =================================================================== RCS file: /cvsroot/mockpp/mockpp/mockpp/docs/en/dev_advanced_jmock.docbook,v retrieving revision 1.17 retrieving revision 1.18 diff -u -d -r1.17 -r1.18 --- dev_advanced_jmock.docbook 2 Dec 2005 17:28:36 -0000 1.17 +++ dev_advanced_jmock.docbook 27 Dec 2005 18:01:44 -0000 1.18 @@ -79,7 +79,7 @@ <para>Chainable mock objects provide <emphasis>stubbed</emphasis> and <emphasis>expected</emphasis> methods. An expected method must occur as specified, otherwise the object will fail when verified. A stubbed method -without specifiction may be invoked unlimited times or not at all +without specification may be invoked unlimited times or not at all but the test still passes.</para> <para>In general, you will <emphasis>stub</emphasis> when you want to get some @@ -166,7 +166,7 @@ <listitem><classname>Or</classname> = <methodname>logic_or()</methodname> provides a logical-or of two constraints</listitem> <listitem><classname>IsAnything</classname> = <methodname>any()</methodname> is always true</listitem> <listitem><classname>IsNothing</classname> = <methodname>nothing()</methodname> is never true</listitem> - <listitem><classname>StringContains</classname> = <methodname>stringContains()</methodname> checks for the occurence of a substring</listitem> + <listitem><classname>StringContains</classname> = <methodname>stringContains()</methodname> checks for the occurrence of a substring</listitem> <listitem><classname>IsInstanceOf</classname> = <methodname>isA()</methodname> tests if an object is of a type</listitem> </itemizedlist> @@ -198,7 +198,7 @@ <sect4 id="comparing-constraint"> <title>Constraints for Comparison</title> -<para>&mockpp; contains two conststraint classes to compare objects. +<para>&mockpp; contains two constraint classes to compare objects. <classname>IsEqual</classname> is probably appropriate for most cases. It takes an object and stores it's value for later comparison.</para> @@ -207,7 +207,7 @@ of two objects. There is a template function <function>isSameComparison</function> which implements this default behaviour. If you need a differing implementation for a certain class you can provide -a specialized template. This may happen if you are using a shared pointer and +a specialised template. This may happen if you are using a shared pointer and don't want to compare the helper but the shared object at the end of the pointers.</para> @@ -223,7 +223,7 @@ <classname>IsEqual</classname> and <classname>IsSame</classname> in exactly the same manner. Unfortunately this may now lead to dangling pointers and crashes if -existing code referes to temporary objects.</para> +existing code refers to temporary objects.</para> <para>The following fragment shows the problem. When constructing the object a temporary string is created and this pointer is Index: dev_advanced_intro.docbook =================================================================== RCS file: /cvsroot/mockpp/mockpp/mockpp/docs/en/dev_advanced_intro.docbook,v retrieving revision 1.9 retrieving revision 1.10 diff -u -d -r1.9 -r1.10 --- dev_advanced_intro.docbook 2 Dec 2005 17:28:36 -0000 1.9 +++ dev_advanced_intro.docbook 27 Dec 2005 18:01:44 -0000 1.10 @@ -12,7 +12,7 @@ <para>To emulate the behaviour of an object in your production code you need more than just single values that meet your expectations. Usually you need a collection of the different expectation types and some code -to generate a deterministic and predictible behaviour to test a limited area.</para> +to generate a deterministic and predictable behaviour to test a limited area.</para> <para>The following methods all require a separation of the code under test and the code using it. But most of the times you would split the two parts @@ -117,14 +117,14 @@ <classname>VisitableMockObject</classname>. It was named like this because you set up part of its behaviour by recording an execution path for the tests, thus by "visiting" the object. This approach is rather strict because the invocation order -and parameter values must match exactly. Unfortunatley it is almost impossible to add +and parameter values must match exactly. Unfortunately it is almost impossible to add new capabilities. </listitem> <listitem>The second approach is represented by the class <classname>ChainableMockObject</classname>. The name stems from the fact that you define the -behaviour with a "chain" of invocations of a helper object. Each chain link sets a contraint, a return -value or some other aspect. The big benefit from this approach is the extensiblity +behaviour with a "chain" of invocations of a helper object. Each chain link sets a constraint, a return +value or some other aspect. The big benefit from this approach is the extensibility concerning the behaviour by simply feeding it new objects which reflect your needs. Therefor it is far more flexible in execution: everything depends on user defined objects outside the mock object. A large set of such classes is already included.</listitem> @@ -157,7 +157,7 @@ <para>But caution: if you take the wrong macro or maybe just have a small typo you will get loads of error messages all pointing to the same line. I strongly recommend to take little steps when setting up such objects: add one single method and compile. To get started I recommend to - use the "recipies" below.</para> + use the "recipes" below.</para> <para>If you want to have an overview what is created behind the scenes, look at <filename>chainable-template.h</filename> and @@ -169,7 +169,7 @@ <listitem><para>The newer and recommended approach with the help of mock methods. The methods are templates which wrap the method under test. Since they are fully - accessible in constrast to an obscure macro they are easier to use and better to debug.</para> + accessible in contrast to an obscure macro they are easier to use and better to debug.</para> <para>For both the Visitable and the Chainable types there are sets of templates for mock methods according to the number of parameters the method under test takes. @@ -253,7 +253,7 @@ <itemizedlist> <listitem> <para> - The macro for the initializer list in the constructor is built like this: + The macro for the initialiser list in the constructor is built like this: <itemizedlist> <listitem>Always start with <token>MOCKPP_CONSTRUCT_MEMBERS_FOR_</token></listitem> <listitem>If the method is of type <token>void</token> add <token>VOID_</token></listitem> @@ -300,7 +300,7 @@ <listitem>A void and const method without parameters in a visitable mock object and extended parameter values and method name: <token>MOCKPP_VOID_CONST_VISITABLE_EXT0</token></listitem> - <listitem>Macro for initializer list for a void method with 2 parameters: + <listitem>Macro for initialiser list for a void method with 2 parameters: <token>MOCKPP_CONSTRUCT_MEMBERS_FOR_VOID_CHAINABLE2</token></listitem> </itemizedlist> @@ -331,7 +331,7 @@ <sect3 id="auto-verify"> <title>Automated Verification</title> -<para>After the last invocation to a mock object has occured you should always invoke +<para>After the last invocation to a mock object has occurred you should always invoke <methodname>verify()</methodname> on the mock object to verify all pending expectations. Maybe there are some unused return objects or outstanding calls. If you use &cppunit; as test framework you should use <classname>VerifyingTestCase</classname> from &mockpp; Index: dev_helper.docbook =================================================================== RCS file: /cvsroot/mockpp/mockpp/mockpp/docs/en/dev_helper.docbook,v retrieving revision 1.10 retrieving revision 1.11 diff -u -d -r1.10 -r1.11 --- dev_helper.docbook 25 Jul 2005 19:02:14 -0000 1.10 +++ dev_helper.docbook 27 Dec 2005 18:01:44 -0000 1.11 @@ -33,7 +33,7 @@ MOCKPP_ASSERT_FALSE(condition); MOCKPP_ASSERT_EQUALS(a, b); MOCKPP_ASSERT_DELTA(a, b, delta); <co id="delta-co" linkends="assert-delta" /> - MOCKPP_ASSERT_BOUNDARY(lo, up, a); <co id="boundary-co" linkends="assert-boudary" /> + MOCKPP_ASSERT_BOUNDARY(lo, up, a); <co id="boundary-co" linkends="assert-boundary" /> MOCKPP_ASSERT_INCLUDES(substr, target); <co id="includes-co" linkends="assert-includes" /> MOCKPP_ASSERT_EXCLUDES(substr, target); MOCKPP_ASSERT_STARTSWITH(substr, target); @@ -96,7 +96,7 @@ <para>A lot of people are using the <methodname>printf()</methodname> family for outputting. Unfortunately these are not typesafe. And nor are they appropriate for -translations when the positions of the substituted parameters are swaped for +translations when the positions of the substituted parameters are swapped for grammatical reasons.</para> <para>So I decided to implement a typesafe approach which also takes into account @@ -107,7 +107,7 @@ <para>The built-in methods handle the common data types like <token>int</token>, <token>float</token> or <token>std::string</token>. -But it is also easily possible to extend the ouput capabilities for your own data types. +But it is also easily possible to extend the output capabilities for your own data types. No changes inside the &mockpp; framework are needed, it needn't even be in the &mockpp; namespace.</para> Index: dev_production.docbook =================================================================== RCS file: /cvsroot/mockpp/mockpp/mockpp/docs/en/dev_production.docbook,v retrieving revision 1.5 retrieving revision 1.6 diff -u -d -r1.5 -r1.6 --- dev_production.docbook 19 Nov 2005 19:14:29 -0000 1.5 +++ dev_production.docbook 27 Dec 2005 18:01:44 -0000 1.6 @@ -7,12 +7,12 @@ <title>Support for Production Code</title> <para>To effectively benefit from unit tests it is frequently necessary to - optimize production code. The following sections show some of the + optimise production code. The following sections show some of the possibilities. The common pattern is as usual to delegate the detailed work - to a helper class which is approriately instantiated.</para> + to a helper class which is appropriately instantiated.</para> <para>Some of the following approaches have the drawback to weaken the - protection of your class mebers. You have to decide yourself if this is + protection of your class members. You have to decide yourself if this is acceptable for you.</para> <para>But you should keep in mind that mechanisms like @@ -26,9 +26,9 @@ <sect2 id="reproducible-time-values"> <title>Reproducible Time Values</title> - <para>Sometimes you need predictible time values. Either you want to - minimize the impact of timeouts in error conditions or prevent idle times. - <application>mockpp</application> contains a sample imlementation of how + <para>Sometimes you need predictable time values. Either you want to + minimise the impact of timeouts in error conditions or prevent idle times. + <application>mockpp</application> contains a sample implementation of how to handle calls to <methodname>std::time()</methodname>. This only covers a resolution of 1 second. If you need a more sophisticated solution you have to create your own code similar to this example. See the sources and |
