Updated documentation

git-svn-id: https://svn.code.sf.net/p/turtle/code/trunk@731 860be788-9bd5-4423-9f1e-828f051e677b
This commit is contained in:
mat007 2014-05-20 05:56:37 +00:00
parent 086a42e432
commit 7cc5feeea0
3 changed files with 23 additions and 9 deletions

View file

@ -0,0 +1,20 @@
// http://turtle.sourceforge.net
//
// Copyright Mathieu Champlon 2014
//
// Distributed under the Boost Software License, Version 1.0.
// (See accompanying file LICENSE_1_0.txt or copy at
// http://www.boost.org/LICENSE_1_0.txt)
#include <turtle/mock.hpp>
#include "calculator.hpp"
#include "mock_view.hpp"
//[ overflow_throws
BOOST_AUTO_TEST_CASE( overflow_throws )
{
mock_view v;
calculator c( v );
BOOST_CHECK_THROW( c.add( std::numeric_limits< int >::max(), 1 ), std::exception );
}
//]

View file

@ -2,7 +2,7 @@
[quickbook 1.5] [quickbook 1.5]
[/ [authors [Champlon, Mathieu]] ] [/ [authors [Champlon, Mathieu]] ]
[authors [,A C++ mock object library for Boost]] [authors [,A C++ mock object library for Boost]]
[copyright 2008-2013 Mathieu Champlon] [copyright 2008-2014 Mathieu Champlon]
[license [license
Distributed under the [@http://www.boost.org/LICENSE_1_0.txt Boost Software License, Version 1.0]. Distributed under the [@http://www.boost.org/LICENSE_1_0.txt Boost Software License, Version 1.0].
] ]

View file

@ -1,4 +1,5 @@
[section:rationale Rationale] [section:rationale Rationale]
[import example/rationale.cpp]
This section explains some of the design and implementation choices. This section explains some of the design and implementation choices.
@ -14,14 +15,12 @@ Several design choices follow the same motivation :
* both const and non-const versions of a method are mocked by default * both const and non-const versions of a method are mocked by default
* the short-cuts for adding constraints cover 95% of the use cases * the short-cuts for adding constraints cover 95% of the use cases
* non-serializable types do not yield compilation errors but are logged as '?' by default * non-serializable types do not yield compilation errors but are logged as '?' by default
* etc..
At the same time customizing any aspect of the library should require minimum effort, for instance : At the same time customizing any aspect of the library should require minimum effort, for instance :
* custom constraints can be any functors, including free functions * custom constraints can be any functors, including free functions
* customizing the logging of a type is done by defining a serialization operator * customizing the logging of a type is done by defining a serialization operator
* integrating into a test framework is made possible by writing a simple custom policy * integrating into a test framework is made possible by writing a simple custom policy
* etc..
[endsect] [endsect]
@ -29,12 +28,7 @@ At the same time customizing any aspect of the library should require minimum ef
By design the exceptions thrown upon error should not inherit from std::exception, for instance consider the following test case based on the example from the [link turtle.motivation motivation] section : By design the exceptions thrown upon error should not inherit from std::exception, for instance consider the following test case based on the example from the [link turtle.motivation motivation] section :
BOOST_AUTO_TEST_CASE( overflow_throws ) [overflow_throws]
{
mock_view v;
calculator c( v );
BOOST_CHECK_THROW( c.add( std::numeric_limits< int >::max(), 1 ), std::exception );
}
Any call to 'v' will be unexpected and yield an exception, which if it were an std::exception would erroneously make the test succeed whereas it is supposed to pass only if the operation overflows (thus not triggering 'v'). Any call to 'v' will be unexpected and yield an exception, which if it were an std::exception would erroneously make the test succeed whereas it is supposed to pass only if the operation overflows (thus not triggering 'v').