Turned documentation code into example code

git-svn-id: https://svn.code.sf.net/p/turtle/code/trunk@578 860be788-9bd5-4423-9f1e-828f051e677b
This commit is contained in:
mat007 2012-11-28 23:01:45 +00:00
parent af5f82a29d
commit d29397417e
10 changed files with 437 additions and 224 deletions

View file

@ -1,24 +1,17 @@
[section Getting Started]
[import example/getting_started.cpp]
This section introduces most of the library features in a series of use cases built on the example from the [link turtle.motivation motivation] section.
For all the code examples the following is assumed :
#define BOOST_AUTO_TEST_MAIN
#include <boost/test/auto_unit_test.hpp>
#include <turtle/mock.hpp>
[prerequisite]
[section Create, expect, trigger, verify]
A simple unit test with mock objects usually splits into several phases as illustrated by :
BOOST_AUTO_TEST_CASE( zero_plus_zero_is_zero )
{
mock_view v; // create mock objects
calculator c( v ); // create object under test
MOCK_EXPECT( v.display ).once().with( 0 ); // configure mock objects
c.add( 0, 0 ); // exercise object under test
} // verify mock objects
[phases]
Triggering the object under test in turn calls methods on the mock objects, and any unexpected call raises an error.
@ -28,19 +21,7 @@ More sophisticated tests sometimes require more complex use cases and in particu
Here is an example highlighting the different possibilities :
BOOST_AUTO_TEST_CASE( zero_plus_zero_is_zero )
{
mock_view v;
calculator c( v );
MOCK_EXPECT( v.display ).once().with( 0 );
c.add( 0, 0 );
MOCK_VERIFY( v.display ); // verify all expectations are fulfilled for the 'display' method
mock::verify( v ); // verify all expectations are fulfilled for all methods of 'v'
mock::verify(); // verify all expectations are fulfilled for all existing mock objects
MOCK_RESET( v.display ); // reset all expectations for the 'display' method
mock::reset( v ); // reset all expectations for all methods of 'v'
mock::reset(); // reset all expectations for all existing mock objects
} // automatically verify all expectations are fulfilled for all mock objects going out of scope
[verify_reset]
Note that all verifications upon destruction will be disabled if the mock objects are destroyed in the context of an exception being raised.
@ -50,14 +31,7 @@ Note that all verifications upon destruction will be disabled if the mock object
A method can be configured with several expectations, for instance :
BOOST_AUTO_TEST_CASE( zero_plus_zero_is_zero )
{
mock_view v;
calculator c( v );
MOCK_EXPECT( v.display ).once().with( 0 ); // this call must occur once (and only once)
MOCK_EXPECT( v.display ).with( 1 ); // this call can occur any number of times (including never)
c.add( 0, 0 );
}
[expectations]
Each method call is then handled by processing the expectations in the order they have been defined :
@ -68,34 +42,13 @@ An error is raised if none can be found.
By default the relative order of the calls does not matter. It can however be enforced :
BOOST_AUTO_TEST_CASE( zero_plus_zero_is_zero )
{
mock_view v;
calculator c( v );
mock::sequence s;
MOCK_EXPECT( v.display ).once().with( 0 ).in( s ); // add this expectation to the sequence
MOCK_EXPECT( v.display ).with( 1 ).in( s ); // add this expectation to the sequence after the previous one
c.add( 0, 0 );
c.add( 1, 0 );
}
[sequence]
Therefore an error will be issued if the second expectation is matched before the first one has been exhausted.
An expectation can be part of several sequences :
BOOST_AUTO_TEST_CASE( zero_plus_zero_is_zero )
{
mock_view v;
calculator c( v );
mock::sequence s1, s2;
MOCK_EXPECT( v.display ).once().with( 0 ).in( s1 );
MOCK_EXPECT( v.display ).once().with( 1 ).in( s2 );
MOCK_EXPECT( v.display ).with( 2 ).in( s1 ).in( s2 ); // add this expectation to both sequences after the previous ones
c.add( 0, 0 );
c.add( 1, 0 );
c.add( 1, 1 );
c.add( 2, 0 );
}
[several_sequences]
[endsect]