\n Distributed under the Boost Software License, Version 1.0. (See accompanying\n file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)\n
\n Unit testing helps us to find bugs \"in the small\"; little implementation\n details that we got wrong while we were building a function, a method or\n a class. When we test each class as an isolated unit, we can miss errors\n in the way two classes interact or in the way a whole ensemble of classes\n cooperate in an integrated system.\n
\n
\n An acceptance test is an automated test that exercises our system as an integrated\n whole and not as a collection of isolated units. In a unit test, we decouple\n ourselves from the execution environment in order to test a piece of code\n in isolation. In an acceptance test, we run the whole system and provide\n controlled inputs to the system. This may consist of prepared input data\n files, prepared input databases and so-on.\n
\n
\n Using these two forms of automated testing, we can use them as a vise to\n squeeze bugs between the two forms of automated tests. Unit tests push from\n below and acceptance tests push from above.\n
\n
\n While the facilities in Boost.Test can be used to create an automated acceptance\n test, the tools are fairly low-level for the kinds of high-level criteria\n that an acceptance test would use. Acceptance tests are usually defined by\n the product\n owner or customer and will describe acceptance criteria in the language\n closest to the problem domain and farthest away from the details of the implementation.\n
\n
\n A better approach for automated acceptance tests would be a tool such as\n FitNesse that is designed for\n automated acceptance testing.\n
\n To use the implementation of main provided by Boost.Test,\n exactly one source file must define BOOST_TEST_MAIN\n before including <boost/test/unit_test.hpp>. If\n multiple source files define BOOST_TEST_MAIN,\n then a multiply defined symbol error will occur during linking.\n
\n
\n If BOOST_TEST_NO_MAIN\n is defined, then no implementation of main will be provided\n and the test executable must provide an initialization function. The exact\n initialization function that must be provided varies depending on how the\n library is compiled. The details are shown in the discussion of each compilation\n variation.\n
\n
\n When Boost.Test is compiled as a library, BOOST_TEST_NO_MAIN\n must be defined when the library is compiled for it to work properly in\n those circumstances.\n
\n The entire unit test framework can be incorporated into an executable by\n including the file <boost/test/included/unit_test.hpp>.\n Because the entire implementation is incorporated into the source file\n including this header, only a single source file in the test executable\n can include this header.\n
\n
\n Additional source files must define BOOST_TEST_NO_LIB\n before including <boost/test/unit_test.hpp> to\n prevent any automatic linking to a shared library. If additional source\n files attempt to include <boost/test/included/unit_test.hpp>,\n a multiply defined symbol error will occur during linking.\n
\n
\n
\n
// In exactly one source file:\n#include<boost/test/included/unit_test.hpp>\n\n// test cases (optional)\n
\n
\n
\n
// In additional source files\n#defineBOOST_TEST_NO_LIB\n#include<boost/test/unit_test.hpp>\n\n// test cases\n
\n
\n
\n
\n If BOOST_TEST_NO_MAIN\n is defined, then an implementation of main must be provided\n that executes the test cases. This is most readily done by delegating to\n unit_test_main.\n
\n
\n
\n
// In exactly one source file\n#defineBOOST_TEST_NO_MAIN\n#include<boost/test/unit_test.hpp>\n\nboost::unit_test::test_suite*init_function(intargc,char*argv[])\n{\n // create test cases and suites and return a pointer to any enclosing\n // suite, or 0.\n return0;\n}\n\nintmain(intargc,char*argv[])\n{\n return::boost::unit_test::unit_test_main(&init_function,argc,argv);\n}\n
\n A lightweight, minimal version of the testing framework can be obtained\n by including <boost/test/minimal.hpp>. This header\n provides only the following macros:\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Macro\n
\n
\n
\n
\n Meaning\n
\n
\n
\n\n
\n
\n
\n BOOST_CHECK(expression)\n
\n
\n
\n
\n If expression is false, the test fails and\n test execution continues.\n
\n
\n
\n
\n
\n
\n BOOST_REQUIRE(expression)\n
\n
\n
\n
\n If expression is false, the test fails and\n test execution terminates.\n
\n
\n
\n
\n
\n
\n BOOST_ERROR(message)\n
\n
\n
\n
\n Report message, fail the test and continue\n test execution.\n
\n
\n
\n
\n
\n
\n BOOST_FAIL(message)\n
\n
\n
\n
\n Report message, fail the test and terminate\n test execution.\n
\n
\n
\n\n
\n
\n The header supplies an implementation of main that executes\n a single test case by calling a free function named test_main\n with the following signature:\n
\n
\n
\n
inttest_main(intargc,char*argv[]);\n
\n
\n
\n
\n The arguments argc and argv are passed\n to test_main from the implementation of main\n supplied by the test framework. No command-line argument processing is\n performed by main. A summary report of errors recorded\n by the test case is printed out after executing the test case. If any exception\n is thrown by the test case, it is caught by main and\n treated as an error from the test case.\n
\n
\n
\n
#include<boost/test/minimal.hpp>\n\ninttest_main(intargc,char*argv[])\n{\n // test case\n}\n
\n To build Boost.Test as a shared library, first build the boost build tools,\n as described in the Getting\n Started documentation. After you have bootstrapped the build tools,\n build the test library with by invoking b2 with arguments\n similar to the following:\n
\n
\n
\n
b2--with-testlink=shared
\n
\n
\n
\n This will place the resulting libraries in stage/lib\n at the top level of the boost tree.\n
\n
\n In a shared library configuration, Boost.Test is compiled into a single\n shared library named boost_unit_test_framework and the\n test executable is linked against that library to import symbols from the\n library. The Boost.Test shared library must be available to the runtime\n loader in order for the tests to execute. Every compilation unit that includes\n a header from Boost.Test must define BOOST_TEST_DYN_LINK\n first so that declarations are properly annotated as imported symbols.\n When BOOST_TEST_DYN_LINK\n is defined, Boost.Test also defines BOOST_TEST_ALTERNATIVE_INIT_API.\n
\n
\n Exactly one compilation unit in the test executable should define BOOST_TEST_MAIN,\n in order run the tests.\n
\n
\n
\n
// In exactly one compilation unit\n#defineBOOST_TEST_DYN_LINK\n#defineBOOST_TEST_MAIN\n#include<boost/test/unit_test.hpp>\n\n// test cases (optional)\n
\n
\n
\n
\n Additional source files define BOOST_TEST_DYN_LINK,\n include the main unit test header and define more test cases and/or suites.\n
\n
\n
\n
// In additional source files\n#defineBOOST_TEST_DYN_LINK\n#include<boost/test/unit_test.hpp>\n\n// test cases\n
\n
\n
\n
\n To compile the library with no implementation of main,\n add BOOST_TEST_NO_MAIN\n to the cxxflags property for b2:\n
// In exactly one source file\n#defineBOOST_TEST_NO_MAIN\n#include<boost/test/unit_test.hpp>\n\nboolinit_function()\n{\n // create test cases and suites and return a boolean indicating\n // success (true) or failure (false).\n returntrue;\n}\n\nintmain(intargc,char*argv[])\n{\n return::boost::unit_test::unit_test_main(&init_function,argc,argv);\n}\n
\n To build Boost.Test as a static library, first build the boost build tools,\n as described in the Getting\n Started documentation. After you have bootstrapped the build tools,\n build the test library with by invoking b2 with arguments\n similar to the following:\n
\n
\n
\n
b2--with-testlink=static
\n
\n
\n
\n This will place the resulting libraries in stage/lib\n at the top level of the boost tree.\n
\n
\n In a static library configuration, Boost.Test is compiled into a single\n static library named boost_unit_test_framework and the\n test executable is linked against that library. Exactly one compilation\n unit in the test executable should define BOOST_TEST_MAIN,\n in order run the tests.\n
\n
\n
\n
// In exactly one source file\n#defineBOOST_TEST_MAIN\n#include<boost/test/unit_test.hpp>\n\n// test cases (optional)\n
\n
\n
\n
\n Additional source files simply include the main unit test header and define\n more test cases and/or suites.\n
\n
\n
\n
// In additional source files\n#include<boost/test/unit_test.hpp>\n\n// test cases\n
\n
\n
\n
\n To compile the library with no implementation of main,\n add BOOST_TEST_NO_MAIN\n to the cxxflags property for b2:\n
// In exactly one source file\n#defineBOOST_TEST_NO_MAIN\n#include<boost/test/unit_test.hpp>\n\nboost::unit_test::test_suite*init_function(intargc,char*argv[])\n{\n // create test cases and suites and return a pointer to any enclosing\n // suite, or 0.\n return0;\n}\n\nintmain(intargc,char*argv[])\n{\n returnboost::unit_test::unit_test_main(init_function,argc,argv);\n}\n
\n The minimal header can be useful in situations where you don't already have\n the library built and want to quickly explore a test with a minimal amount\n of fuss. Once you need to create multiple unit tests, you will quickly outgrow\n the minimal header.\n
\n
\n The header only form is useful when you don't want to be bothered with compiling\n the library. Once you have multiple compilation units with unit tests in\n each compilation unit, you will grow tired of the compilation cost involved\n with the header only form of the framework.\n
\n
\n The static library form is the easiest to integrate into your build system\n as it doesn't require any installation of runtime files in order to execute\n your tests. This runtime simplicity comes at the cost of increased link times\n and executable sizes.\n
\n
\n The dynamic library form requires the most effort for successful test execution,\n but provides faster link times than the static library, faster compile times\n than the header only form and provides all the features of the framework\n compared to the minimal header.\n
\n
\n
\n
\n
Caution
\n
\n
\n Boost.Test is not a thread-safe library. Care should be taken when automated\n tests create multiple threads and interact with data structures passed\n to Boost.Test macros or functions.\n
\n You may have an existing body of tests that you wish to register with Boost.Test\n manually. You can use BOOST_TEST_CASE\n to register a function taking no arguments and returning void\n as a test case:\n
\n You can use a test case method on a fixture class by registering a function\n that creates an instance of the fixture and invokes the test method. This\n assures that a fresh fixture is created for each test case, ensuring that\n each test executes independently of other tests.\n
\n You can register a method on a class as a test case by using Boost.Bind to\n bind the method to a static instance of the class. This can cause oen test\n case to influence the execution of another test case because they share the\n static fixture.\n
\n A static instance of the class is used so that the instance exists at the\n time the test case is invoked. Test case invocation happens after registration,\n so using a local instance in the registration function is insufficient.\n
\n A new test suite is created with the BOOST_TEST_SUITE\n macro. The new suite must be added to the master test suite to execute its\n tests. Any number of test suites can be added in a hierarchy of suites and\n any test case can be added to any test suite.\n
\n In testing file I/O, we\n showed an example of creating a class fake_directory_scanner\n that acted as a simple test double for an interface. Such simple fake objects\n are fine at first, but they're full of boring boiler plate code and after\n a while it becomes tedious to write them by hand.\n
\n
\n For collaborators defined by a pure virtual base class, also known as an\n interface, there are mock object frameworks that alleviate the need to write\n the repetitive boiler plate code. One such mock object framework that is\n designed to work with Boost.Test is the Turtle\n mock object framework.\n
\n
\n Here is an example of the file system tests written using turtle:\n
\n Defining the mock object is considerably simpler than writing a fake object\n by hand. Turtle uses variadic argument macros and template based type deduction\n to infer the type signature of the methods simply from the number of arguments\n each method takes. This alleviates us from having to repeat all of this information\n from the interface into the implementation of the test double.\n
\n
\n Now we can rewrite our tests to use a mock object configured for each test\n case:\n
\n The tests themselves are largely unchanged and what is different is the intention\n revealing methods we placed in the test fixture. Mock object frameworks generally\n provide a rich set of methods on the mock object for setting the expectations\n on the number of times a method is called, such as once(),\n the expected arguments to a method, such as with(), and\n the return value of a method, such as returns().\n
\n
\n With a turtle mock, the expectations are verified when the mock object is\n destroyed. The mock is a member in our fixture and will be destroyed at the\n end of every test case.\n
\n xUnit\n Patterns[2], by Gerard Meszaros, presents several high level objectives for\n automated tests and individual goals for achieving those objectives:\n
\n
\n
\n Objective: Tests should help us improve quality.\n
\n In this section, we will discuss how the facilities in Boost.Test can support\n these goals; see xUnit Patterns for the description\n and rationale of these goals.\n
\n Tests can serve as specifications for the system under test if we write the\n test for the system first, using test-driven development. We imagine the\n perfect system that does exactly what we need and write a test as if that\n system existed. In order to achieve a failing test, we write just enough\n of the implementation to make the test compile.\n
\n
\n A good way to ensure that the implementation causes a test failure is for\n called methods and functions to throw an exception indicating that the method\n or function called is not implemented:\n
\n
#include<stdexcept>\n\nvoidfree_function()\n{\n throwstd::runtime_error(\"free_function not implemented.\");\n}\n
\n
\n We get a failing test right away, while still satisfying just enough syntax\n to satisfy the compiler.\n
\n It is well known that the longer a bug remains undetected in a software,\n the more expensive it is to fix.[3] If we are practicing test-driven development, then we find bugs\n in our implementation as soon as we code them. The time to find a bug in\n this manner can be as little as seconds and was demonstrated in the tutorial\n \"Hello, Test!\".\n
\n
\n The easiest way to achieve this rapid feedback is to run the tests as part\n of the build. The details vary depending on your build system.\n
\n
\n In Visual Studio 2012, this is most readily achieved by setting a post-build\n build event as shown below. Because $(TargetPath) may\n contain spaces, the variable is surrounded by double quotes to ensure that\n the entire path to the executable is found. The description is given generically\n using $(TargetName) so that this build event can be copied\n to any test project's properties and be used without modification. Take care\n that you define the build event for all configurations and all platforms\n used by your build system so that the unit tests always run.\n
\n
\n \n
\n
\n If you are using a Makefile to compile your code, create\n a phony target that depends on your unit test executable and specify the\n command to execute your unit test and create the phony target if the test\n passes. This will ensure that the unit tests continue to run as long as they\n fail because the phony target will only be updated when the tests pass.\n
\n
\n If you are using Boost.Build and Jamfiles to compile your code, you can use\n the rules in the testing module to incorporate your unit\n tests into your build. The unit-test rule will build an\n executable and run it, failing the build when the executable returns a non-zero\n exit status. Other rules in the testing module may also\n be useful.\n
\n If we keep our test cases focused on only a single behavior in our system\n under test, then there is only a single cause for any particular unit test\n to fail. We saw this in \"Testing\n With Exceptions\" when we added a new test case to hello_world\n for a bad stream. By choosing intention\n revealing names for our test cases, we can identify the source of\n the failure simply by reading the name of the failed test case.\n
\n
\n Since each test case excercises only one scenario for the system under test,\n we must make at least one test case for each possible scenario. We can use\n the cyclomatic\n complexity as a rough proxy for the number of tests cases needed\n for any particular method or function to ensure that we have sufficient\n coverage\n of the system under test.\n
\n When confronted with a new software component or a new code base, how do\n we understand its behavior? We can read the documentation, but ultimately\n the behavior is defined by the code executed. Comments and documentation\n can lag the actual implementation. Sometimes, the only answer to our questions\n about a software component come from the implementation. If the component\n is only available to us in binary form, we don't have the luxury of consulting\n the source code in order to answer our questions.\n
\n
\n Unit tests can serve as a form of executable documentation for software components.\n They tell us how the system responds to the scenarios orchestrated by the\n test cases.\n
\n
\n When faced with a confusing aspect of a software component, we can answer\n questions about the behavior of the component by writing a unit test that\n describes our hypothesis about the component's behavior. If the unit test\n passes, we have verified our hypothesis. If the unit test fails, our hypothesis\n was incorrect; either way, we have learned something about the component.\n We can use unit tests to document subtle and unexpected behaviors of components.\n Unit tests are also the perfect documentation for a bug report on a component\n maintained by others.\n
\n When we start building a software system, we are able to keep all the details\n of the system in our mind because the system is small. As the size of the\n system increases, it becomes harder and harder to keep all the details of\n the system in mind as we make modifications. A comprehensive suite of unit\n tests over the system give us an automated regression test that gives us\n the confidence of knowing that our changes are not introducing any problems\n elsewhere in the code.\n
\n Automated tests should only reduce risk, not introduce risk into the system.\n To achieve this, we want to keep all test code separated from production\n code. The easiest way to do this is to put the system under test into a library\n (static or shared) and link the test executable against the library. We saw\n this in the tutorial \"Hello,\n Test!\", when we separated the system under test into the hello\n library and the test code into test_hello.cpp.\n
\n Boost.Test supports fully automated tests by allowing us to supply the inputs\n to the system under test in each test case in order to drive the system into\n the scenario of interest. Test cases should never rely on user input, or\n they will not be fully automated tests that can run unattended.\n
\n Boost.Test supports self-checking tests through its rich set of assertions.\n Each test case supplies the inputs to the system under test and validates\n the behavior of the system using assertions. Self-checking tests report only\n bad news and good news results in no notifications. The default output from\n the test runner only reports failing tests and a summary of all tests executed.\n The test runner also returns a non-zero status code when a test fails, allowing\n easy failure of continuous\n integration builds.\n
\n We should get the same results from automated tests every time we run them,\n provided the implementation of the system under test has not changed between\n runs. In the context of unit testing, this implies that a test case must\n control all the collaborators that can influence the system.\n
\n
\n The most troublesome collaborators are among the following: * current date\n and time * device input * file system * system services (Windows registry,\n networking, etc.) * C style apis\n
\n
\n In the book \"Working Effectively with Legacy Code\", Michael Feathers\n described a number of techniques for decoupling the system under test from\n such troublesome collaborators that can cause unit tests to spuriously fail.\n All the techniques are variations on a theme: introduce a level of indirection\n to decouple the system under test from a collaborator. C++ offers static\n polymorphism via templates as well as the usual dynamic polymorphism\n via interfaces to decouple a system under test from a collaborator.\n
\n We keep tests simple by exercising only one scenario for each test case.\n Simple test cases read linearly through the phases of setup, exercise and\n verify. Trying to exercise too much functionality in a single test case can\n introduce unnecessary complexity into the test.\n
\n
\n Duplication between test cases can make tests hard to read by distracting\n us from the steady rhythm of setup, exercise and verify of test cases. You\n may find it useful to apply the rule\n of three when writing test cases to decide when to extract duplication\n into a fixture.\n
\n Sometimes low-level setup details get in the way of a test reading clearly.\n This could be the result of a complicated data structure needed in order\n to exercise the system down a particular code path. Similarly, the verification\n of a result produced by the system under test may involve a series of assertions\n that make the test hard to follow. Boost.Test provides fixtures as a way\n to localize these distracting details by extracting setup and assertion methods\n into the fixture.\n
\n
\n Over time we build up a series of methods in the fixture that allow us to\n express domain concepts succinctly and clearly in the tests, making them\n more expressive of the scenario in the domain. Fixtures can be combined through\n aggregation or inheritance in order to express combinations and hierarchies\n of domain concepts.\n
\n We keep test code separated from production code with the packaging mechanisms\n provided by C++. Production code is supplied to the test executable as a\n library, either static or dynamic. The test code resides in separate source\n files from the production code. The production code consumed by the test\n code is compiled with the exact same preprocessor settings as the production\n code to ensure that tests do not influence the production code.\n
\n
\n We keep concerns separated in our tests by testing each concern in its own\n test case. Each test case exercises a single scenario and our tests exercise\n the responsibilities or classes individually. If we are practicing test-driven\n development, we keep the single\n responsibility principle in mind as we are creating the system to\n satisfy the evolving tests. When our tests start involving more than one\n concern, it can be a sign that our system under test is covering more than\n one responsibility.\n
\n Test cases are robust when small changes to the system under test result\n in a small number of test cases failing. If a small change to the system\n results in many test cases failing, then our tests are not robust. If our\n tests cases do not sufficiently isolate the system under test from its collaborators,\n then a change to one part of the system can cause tests on seemingly unrelated\n parts of the system to fail. If we have repeated assertions in many test\n cases for the same system under test, then many test cases can fail if that\n single assertion fails. Each of these situations is a case of overlap between\n test cases; in the first case, the overlap is between the parts of the production\n code unrelated to the system under test that we exercise and in the second\n case, the overlap is between test cases on the system under test.\n
\n
\n \n
[2] \n The term xUnit is a generic term for unit testing\n frameworks, such as jUnit. The advice in xUnit Patterns\n applies equally well to Boost.Test.\n
\n If there is considerable logic in an appliation's main\n function, this can be difficult to unit test. The One\n Definition Rule prevents us from having the application's main\n and the unit test executable's main in the same executable.\n Furthermore, even if we could perform some trick to resolve the multiply\n defined symbol[4], we would still need to figure out how to link the test executable\n with the application's main function to test the code.\n
\n
\n When it becomes difficult to test code where it is currently, such as in\n the body of main, the simplest thing to do is to move\n the code somewhere else that makes it easy to test. Here is one way to accomplish\n this:\n
\n
\n
\n rename main to app_main.\n
\n
\n move app_main to a library.\n
\n
\n create a simple delegating main that calls app_main.\n
\n
\n write tests for app_main by linking against the library.\n
\n If you don't already have a library for app_main, then\n create one and add all the other application code to the library as well.\n The build logic for making the executable will consist of compiling a single\n source file containing your delegating implementation of main\n and linking against a library containing the rest of the application. This\n will give you a starting point for writing unit tests for anything in your\n application.\n
\n
\n \n
[4] \n We could abuse the C++ preprocessor or use object file symbol modification.\n
\n A common problem encountered in unit testing is interaction with the file\n system: scanning directories, creating files, opening files, reading files,\n writing files, creating symbolic links and so-on. Interacting directly with\n the file system when executing unit tests can lead to a failure of tests\n to be robust or repeatable.\n We also want our unit tests to be fast; an execution time of 100 milliseconds\n is considered a slow unit test. Interacting directly with the file system\n can make our unit tests take too long to execute.\n
\n
\n The simplest approach is to wrap file system operations in an interface and\n perform all operations through the interface. Consider the following example\n of a function that returns a vector of filenames ending in \".txt\"\n in a given directory:\n
\n How can we unit test text_files without relying on the\n actual contents of the file system? We can decouple text_files\n from the file system by introducing an interface:\n
\n The interface directory_scanner is used to isolate the\n free function text_files from directly interacting with\n the file system. In the unit tests, we use an implementation of directory_scanner\n that senses how text_files uses the interface and allows\n us to control the data made available to text_files. The\n tests can use a hand-crafted fake implementation or an implementation from\n a mock library. The fake might look something like this:\n
\n We've wrapped just enough of Boost.FileSystem for our needs; Boost.FileSystem\n has a very large surface area and we don't need to put an interface around\n the entire thing, just enough to satisfy the needs of text_files.\n
\n
\n If we don't want production code to have to worry about supplying an instance\n of filesystem_directory_scanner to text_files,\n we can use overloading on text_files and use simple delegation\n to supply the dependency:\n
\n Seeing this, you might wonder if we need to unit test the overload we just\n created? Because we are using simple delegation here, there isn't sufficient\n complexity to warrant unit testing. However, we have no unit tests for filesystem_directory_scanner,\n which does have control structures. We will want some sort of automated tests\n around this code to verify that it functions properly. We can use acceptance\n tests to verify the system as a whole, exercising all the components\n end-to-end and not just in isolation.\n
\n A common problem encountered in unit testing is interaction with the file\n system: scanning directories, creating files, opening files, reading files,\n writing files, creating symbolic links and so-on. Interacting directly with\n the file system when executing unit tests can lead to a failure of tests\n to be robust or repeatable.\n We also want our unit tests to be fast; an execution time of 100 milliseconds\n is considered a slow unit test. Interacting directly with the file system\n can make our unit tests take too long to execute.\n
\n
\n The simplest approach is to wrap file system operations in an interface and\n perform all operations through the interface. Consider the following example\n of a function that returns a vector of filenames ending in \".txt\"\n in a given directory:\n
\n How can we unit test text_files without relying on the\n actual contents of the file system? We can decouple text_files\n from the file system by introducing an interface:\n
\n The interface directory_scanner is used to isolate the\n free function text_files from directly interacting with\n the file system. In the unit tests, we use an implementation of directory_scanner\n that senses how text_files uses the interface and allows\n us to control the data made available to text_files. The\n tests can use a hand-crafted fake implementation or an implementation from\n a mock library. The fake might look something like this:\n
\n We've wrapped just enough of Boost.FileSystem for our needs; Boost.FileSystem\n has a very large surface area and we don't need to put an interface around\n the entire thing, just enough to satisfy the needs of text_files.\n
\n
\n If we don't want production code to have to worry about supplying an instance\n of filesystem_directory_scanner to text_files,\n we can use overloading on text_files and use simple delegation\n to supply the dependency:\n
\n Seeing this, you might wonder if we need to unit test the overload we just\n created? Because we are using simple delegation here, there isn't sufficient\n complexity to warrant unit testing. However, we have no unit tests for filesystem_directory_scanner,\n which does have control structures. We will want some sort of automated tests\n around this code to verify that it functions properly. We can use acceptance\n tests to verify the system as a whole, exercising all the components\n end-to-end and not just in isolation.\n
\n When testing a large class, you may find yourself wanting to test protected\n or private members of the class. The best approach is to test those members\n by testing the public members of the class. If using the public members of\n a class requires considerable setup in order to force execution down a particular\n path that exercises the protected or private member in question, then you\n may wish to refactor the code to enhance testability.\n
\n
\n The most expedient technique for protected members is to raise their visibility\n through derivation. Suppose we have a base class B\n with a protected member p\n that we wish to test:\n
\n
classB\n{\n// ... other stuff in B\nprotected:\n boolp();\n};\n
\n
\n We can derive a class D in\n the test code from the class B\n in the production code that raises the visibility of p:\n
\n
classD:publicB\n{\n// ... other stuff needed to build a D from a B\npublic:\n usingB::p;\n};\n
\n
\n Now we can write a test for D::p.\n
\n
\n While this certainly seems expedient, it's annoying to write these derived\n classes simply for the purposes of hoisting members into public visibility.\n It also just feels dirty. We're taking implementation details that are supposed\n to be hidden from consumers of the class and we're exposing them. If we are\n not diligent and watchful, this class D\n in the test project that was only intended for testing may find itself showing\n up in the production code.\n
\n
\n Maybe the problem isn't one of visibility but that we simply aren't listening\n closely enough to the code in the first place. As Herb Sutter shows us in\n Uses and Abuses of Access Rights,\n the \"Liar\", the \"Pickpocket\", the \"Cheat\" and\n the \"Language Lawyer\" can all find ways to subvert the access protections\n afforded to a class.\n
\n
\n When we are tempted to test non-public methods of a class, it's because we\n feel that there is sufficient complexity in these non-public methods to warrant\n testing them. What if that complexity is trying to tell us something? If\n our class is so complex, isn't it possible that it's violating the Single\n Responsibility Principle? Maybe the class is trying to encompass\n several responsibilities and should be decomposed into two or more classes,\n each with a single responsibility. We could perform the Extract\n Class refactoring to create two classes with appropriate public interfaces\n and then write tests against those new public interfaces.\n
\n
\n Another choice is to refactor the original class using the \"pimpl\n idiom\", elevate the visibility to public of all the methods\n on the implementation class and write tests against the implementation class.\n This has the same downsides as the derive-and-elevate approach and we're\n still ignoring the whispers of the code.\n
\n
\n When your code is hard to test, your code is telling you something. Listen\n to the code!\n
\n This documentation provides material for both new users and advanced users.\n If you are completely new to automated testing, you may wish to read Wikipedia's\n article on test-driven\n development and consult the online book xUnit\n Test Patterns. The amount of information available on automated testing\n has exploded in the past decade and these are only some suggested starting\n points and not intended to be an exhaustive list.\n
\n
\n To get started quickly writing your first test, read the tutorial\n sections. For advice on designing and maintaining your tests, read the section\n on test case design. For\n advanced uses of the library, consult the reference.\n
\n Automated tests are an important part of verifying software. At the developer\n level, automated tests provide confidence that changes made to the software\n do not result in new defects. At the customer level, automated tests provide\n confidence that new features meet expectations and existing features continue\n to function unchanged.\n
\n
\n Boost.Test is a library that supports the automated testing of software, primarily\n aimed at satisfying the needs of the developer.\n
\n BITWISE_level_EQUAL(lhs,\n rhs) compares the two arguments\n for bitwise equality and fails if they are not equal. This can be useful\n when testing integral values that represent a logical or combination of\n bit flags.\n
\n BOOST_level_CLOSE(lhs,\n rhs, tolerance)\n compares the two floating-point arguments and considers them equal if they\n agree within the given tolerance. The tolerance\n is given as a percentage.\n
\n BOOST_level_CLOSE_FRACTION(lhs,\n rhs, tolerance)\n compares the two floating-point arguments and considers them equal if they\n agree within the given tolerance. The tolerance\n is given as a percentage.\n
\n BOOST_level_EQUAL_COLLECTIONS(lhs_begin,\n lhs_end, rhs_begin,\n rhs_end) compares two collections\n for equality. Two collections are considered equal if they have the same\n number of elements and the elements compare equal by operator==. The elements are obtained through the\n supplied iterators on the collections. The diagnostic message is constructed\n from applying operator<<\n to each of the elements in the collections.\n
\n
\n
\n
\n
Important
\n
\n
\n If you get a strange compile error when using BOOST_EQUAL_COLLECTIONS,\n check that the appropriate operator== and operator<< are defined for the element type\n in the collection. If you define these operators in your test code, keep\n in mind argument-dependent lookup of types based on enclosing namespaces\n and the namespaces opened by test suites. The need to define operator<<\n can be eliminated by using BOOST_TEST_DONT_PRINT_LOG_VALUE.\n
\n BOOST_level_EXCEPTION(statement,\n exception, predicate)\n asserts that when statement throws an exception\n of type exception, the predicate\n applied to the instance of the exception returns true.\n This is used to verify not only that an exception of the correct type was\n thrown, but that the contents of the thrown exception meet the expectations\n of the predicate.\n
\n BOOST_level_GE(lhs,\n rhs) asserts that lhs\n is greater than or equal to rhs. The comparison\n is made by applying operator>= to both arguments. The diagnostic\n message is constructed from applying operator<< to the two arguments.\n
\n
\n
\n
\n
Important
\n
\n
\n If you get a strange compile error when using BOOST_level_GE,\n check that the appropriate operator>= and operator<< are defined for the arguments.\n If you define these operators in your test code, keep in mind argument-dependent\n lookup of types based on enclosing namespaces and the namespaces opened\n by test suites. The need to define operator<< can be eliminated by using BOOST_TEST_DONT_PRINT_LOG_VALUE.\n
\n BOOST_level_GT(lhs,\n rhs) asserts that lhs\n is greater than rhs. The comparison is made\n by applying operator>\n to both arguments. The diagnostic message is constructed from applying\n operator<<\n to the two arguments.\n
\n
\n
\n
\n
Important
\n
\n
\n If you get a strange compile error when using BOOST_level_GT,\n check that the appropriate operator> and operator<< are defined for the arguments.\n If you define these operators in your test code, keep in mind argument-dependent\n lookup of types based on enclosing namespaces and the namespaces opened\n by test suites. The need to define operator<< can be eliminated by using BOOST_TEST_DONT_PRINT_LOG_VALUE.\n
\n BOOST_level_LE(lhs,\n rhs) asserts that lhs\n is less than or equal to rhs. The comparison\n is made by applying operator<= to both arguments. The diagnostic\n message is constructed from applying operator<< to the two arguments.\n
\n
\n
\n
\n
Important
\n
\n
\n If you get a strange compile error when using BOOST_level_LE,\n check that the appropriate operator<= and operator<< are defined for the arguments.\n If you define these operators in your test code, keep in mind argument-dependent\n lookup of types based on enclosing namespaces and the namespaces opened\n by test suites. The need to define operator<< can be eliminated by using BOOST_TEST_DONT_PRINT_LOG_VALUE.\n
\n BOOST_level_LT(lhs,\n rhs) asserts that lhs\n is less than rhs. The comparison is made by\n applying operator<\n to both arguments. The diagnostic message is constructed from applying\n operator<<\n to the two arguments.\n
\n
\n
\n
\n
Important
\n
\n
\n If you get a strange compile error when using BOOST_level_LT,\n check that the appropriate operator< and operator<< are defined for the arguments.\n If you define these operators in your test code, keep in mind argument-dependent\n lookup of types based on enclosing namespaces and the namespaces opened\n by test suites. The need to define operator<< can be eliminated by using BOOST_TEST_DONT_PRINT_LOG_VALUE.\n
\n BOOST_level_MESSAGE(predicate,\n message) emits message\n if the supplied predicate evaluates to false.\n The message is applied to an output stream with\n operator<<\n and the argument can contain additional applications of operator<< for building up complex messages.\n The predicate can return bool or predicate_result.\n
\n
\n
\n
staticintg_i;\n\n// simple predicate\nstaticboolglobal_int_is_positive()\n{\n returng_i>0;\n}\n\n// predicate that builds up detail message\nstaticboost::test_tools::predicate_resultglobal_int_equal(intexpected)\n{\n if(g_i==expected)\n {\n returntrue;\n }\n\n boost::test_tools::predicate_resultfailed=false;\n failed.message()<<\"g_i != \"<<expected<<\"; actual: \"<<g_i;\n returnfailed;\n}\n\nBOOST_AUTO_TEST_CASE(example_message)\n{\n g_i=1;\n\n BOOST_REQUIRE_MESSAGE(global_int_is_positive(),\n \"g_i is not positive; actual: \"<<g_i);\n BOOST_REQUIRE_MESSAGE(global_int_equal(1),\"\");\n}\n
\n BOOST_level_NE(lhs,\n rhs) asserts that lhs\n is not equal to rhs. The comparison is made\n by applying operator!=\n to both arguments. The diagnostic message is constructed from applying\n operator<<\n to the two arguments.\n
\n
\n
\n
\n
Important
\n
\n
\n If you get a strange compile error when using BOOST_level_NE,\n check that the appropriate operator!= and operator<< are defined for the arguments.\n If you define these operators in your test code, keep in mind argument-dependent\n lookup of types based on enclosing namespaces and the namespaces opened\n by test suites. The need to define operator<< can be eliminated by using BOOST_TEST_DONT_PRINT_LOG_VALUE.\n
\n BOOST_level_PREDICATE(predicate,\n args) asserts that the supplied\n predicate applied to args\n evaluates to true. The supplied predicate must\n have a return type of bool and argument types that are\n compatible with the argument list args. Because\n BOOST_level_PREDICATE\n is a macro, the args must be supplied as a sequence\n of parenthesized values, with no comma separating the values.\n
\n BOOST_TEST_DONT_PRINT_LOG_VALUE(type)\n instructs the test framework to ignore values of type type\n when constructing diagnostic messages. It does this by defining an empty\n implementation of a print function specialized for type.\n Because the specialization is inside an implementation namespace for Boost.Test,\n the macro must be invoked at the global namespace scope. Therefore, it\n cannot be used inside a test suite or any other namespace.\n
\n BOOST_FAIL(message)\n always fails and emits the given message at\n the REQUIRE assertion level. Other assertion macros\n are generally preferred over BOOST_FAIL because they\n emit better diagnostics in the case of failure.\n
\n
\n There are two situations where you might be tempted to use BOOST_FAIL:\n testing the situations where the system under test will throw exceptions\n or comparing against the values computed by the system under test. For\n testing exception generation, use BOOST_REQUIRE_THROW,\n BOOST_REQUIRE_NO_THROW\n or BOOST_REQUIRE_EXCEPTION.\n For testing against values computed by the system under test, use the comparing\n assertions.\n
\n BOOST_EQUAL(lhs, rhs)\n compares the two arguments with operator==. The diagnostic message is constructed\n with operator<<\n on the two arguments.\n
\n
\n
\n
\n
Important
\n
\n
\n If you get a strange compile error when using BOOST_EQUAL,\n check that the appropriate operator== and operator<< are defined for the arguments.\n If you define these operators in your test code, keep in mind argument-dependent\n lookup of types based on enclosing namespaces and the namespaces opened\n by test suites. The need to define operator<< can be eliminated by using BOOST_TEST_DONT_PRINT_LOG_VALUE.\n
\n BOOST_level_EXCEPTION(expression,\n exception, predicate)\n asserts that when expression throws an exception\n of type exception, the predicate\n applied to the instance of the exception returns true.\n This is used to verify not only that an exception of the correct type was\n thrown, but that the contents of the thrown exception meet the expectations\n of the predicate.\n
\n
\n The predicate can return bool,\n or predicate_result\n which allows the predicate to build up a detailed failure message.\n
\n BOOST_level_MESSAGE(predicate,\n message) emits message\n if the supplied predicate evaluates to false.\n The message is applied to an output stream with\n operator<<\n and the argument can contain additional applications of operator<< for building up complex messages.\n The predicate can return bool or predicate_result.\n
\n BOOST_TEST_DONT_PRINT_LOG_VALUE(type)\n instructs the test framework to ignore values of type type\n when constructing diagnostic messages. It does this by defining an empty\n implementation of a print function specialized for type.\n Because the specialization is inside an implementation namespace for Boost.Test,\n the macro must be invoked at the global namespace scope. Therefore, it\n cannot be used inside a test suite or any other namespace.\n
\n When using the library or header-only version of Boost.Test, many assertion\n macros are provided in three levels that determine the behavior when the\n assertion fails and how a failed assertion interacts with the test runner.\n
\n
\n
Table 1.2. Assertion Levels
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Level\n
\n
\n
\n
\n Test Case Fails?\n
\n
\n
\n
\n Aborts Execution?\n
\n
\n
\n\n
\n
\n
\n WARN\n
\n
\n
\n
\n No\n
\n
\n
\n
\n No\n
\n
\n
\n
\n
\n
\n CHECK\n
\n
\n
\n
\n Yes\n
\n
\n
\n
\n no\n
\n
\n
\n
\n
\n
\n REQUIRE\n
\n
\n
\n
\n Yes\n
\n
\n
\n
\n Yes\n
\n
\n
\n\n
\n
\n
\n The WARN level issues a diagnostic message, but the\n test case is not considered to have failed and continues executing. The\n CHECK level issues a message to the test log on failure,\n marks the test case as failed and continues executing. The REQUIRE\n level issues a message to the test log on failure, marks the test case\n as failed and halts execution of the test case.\n
\n Assertions are used to validate the result of exercising the system under\n test. When an assertion fails, a diagnostic message is created and the failed\n assertion is recorded. Different assertion levels allow you to control how\n a failed assertion is interpreted by the test runner.\n
\n
\n
\n
\n
Important
\n
\n
\n When an assertion involves a user-defined datatype, a stream insertion\n operator (operator<<)\n must be defined for the user-defined datatype, or the assertion will fail\n to compile. Asserting a comparison operation on a value of a user-defined\n type will require the appropriate comparison operator (operator<, operator==, etc.) be defiend for the type or the\n assertion will fail to compile. The need to define operator<< can be eliminated by using BOOST_TEST_DONT_PRINT_LOG_VALUE.\n
\n
\n
\n The minimal header\n test framework does not provide the facilities described here.\n
\n When defined, the alternative init_unit_test_func\n test module initialization API is used.\n
\n
\n
\n
\n
\n
\n BOOST_TEST_DYN_LINK\n
\n
\n
\n
\n When defined, the implementation is compiled as a shared library.\n Defining BOOST_TEST_DYN_LINK also defines BOOST_TEST_ALTERNATIVE_INIT_API.\n
\n
\n
\n
\n
\n
\n BOOST_TEST_MAIN\n
\n
\n
\n
\n When defined, an implementation of main is included in the source\n file.\n
\n
\n
\n
\n
\n
\n BOOST_TEST_MODULE\n
\n
\n
\n
\n When defined, it provides the name of the master test suite, otherwise\n a default name is used.\n
\n
\n
\n
\n
\n
\n BOOST_TEST_NO_LIB\n
\n
\n
\n
\n When defined, no automatic linking is performed.\n
\n
\n
\n
\n
\n
\n BOOST_TEST_NO_MAIN\n
\n
\n
\n
\n When defined, no implementation of main is provided in any configuration.\n Static and shared libraries must have been built with this symbol\n defined for it to take effect when using the library. The test\n executable must provide its own implementation of main;\n unit_test_main\n may be used for this purpose.\n
\n
\n
\n\n
\n
\n When using any of these macros, they must be defined before including any\n header from Boost.Test.\n
namespaceboost{\n\nclassexecution_exception{\n typedefboost::unit_test::const_stringconst_string;\npublic:\n enumerror_code{\n no_error=0,\n user_error=200,\n cpp_exception_error=205,\n system_error=210,\n timeout_error=215,\n user_fatal_error=220,\n system_fatal_error=225\n };\n\n structBOOST_TEST_DECLlocation{\n explicitlocation(charconst*file_name=0,size_tline_num=0,charconst*func=0);\n\n const_stringm_file_name;\n size_tm_line_num;\n const_stringm_function;\n };\n\n // Constructor\n execution_exception(error_codeec_,const_stringwhat_msg_,locationconst&location_);// max length 256 inc '\\0'\n\n // Access methods\n error_codecode()const{returnm_error_code;}\n const_stringwhat()const{returnm_what;}\n locationconst&where()const{returnm_location;}\n};// execution_exception\n\nclassexecution_monitor{\n typedefboost::unit_test::const_stringconst_string;\npublic:\n execution_monitor();\n\n // Public properties\n\n // The p_catch_system_errors parameter specifies whether the monitor should \n // try to catch system errors/exceptions that would cause program to crash \n // in regular case\n unit_test::readwrite_property<bool>p_catch_system_errors;\n\n // The p_auto_start_dbg parameter specifies whether the monitor should \n // try to attach debugger in case of caught system error\n unit_test::readwrite_property<bool>p_auto_start_dbg;\n\n // The p_timeout parameter specifies the seconds that elapse before\n // a timer_error occurs. May be ignored on some platforms.\n unit_test::readwrite_property<int>p_timeout;\n\n // The p_use_alt_stack parameter specifies whether the monitor should\n // use alternative stack for the signal catching\n unit_test::readwrite_property<bool>p_use_alt_stack;\n\n // The p_detect_fp_exceptions parameter specifies whether the monitor should\n // try to detect hardware floating point exceptions (!= 0), and which specific exception to catch\n unit_test::readwrite_property<unsigned>p_detect_fp_exceptions;\n\n intexecute(boost::function<int()>const&F);\n // Returns: Value returned by function call F().\n //\n // Effects: Calls executes supplied function F inside a try/catch block which also may\n // include other unspecified platform dependent error detection code.\n //\n // Throws: execution_exception on an uncaught C++ exception,\n // a hardware or software signal, trap, or other exception.\n //\n // Note: execute() doesn't consider it an error for F to return a non-zero value.\n\n voidvexecute(boost::function<void()>const&F);\n // Effects: Same as above, but returns nothing\n\n // register custom (user supplied) exception translator\n template<typenameExceptionType,typenameExceptionTranslator>\n voidregister_exception_translator(ExceptionTranslatorconst&tr,const_stringtag=const_string(),boost::type<ExceptionType>*=0);\n\n // erase custom exception translator\n voiderase_exception_translator(const_stringtag)\n {\n m_custom_translators=m_custom_translators->erase(m_custom_translators,tag);\n }\n template<typenameExceptionType>\n voiderase_exception_translator(boost::type<ExceptionType>*=0)\n {\n m_custom_translators=m_custom_translators->erase<ExceptionType>(m_custom_translators);\n }\n\n};// execution_monitor\n\ntemplate<typenameExceptionType,typenameExceptionTranslator>\nvoid\nexecution_monitor::register_exception_translator(ExceptionTranslatorconst&tr,const_stringtag,boost::type<ExceptionType>*)\n{\n m_custom_translators.reset(\n newdetail::translator_holder<ExceptionType,ExceptionTranslator>(tr,m_custom_translators,tag));\n}\n\nstructexecution_aborted{};\n\nclasssystem_error{\npublic:\n // Constructor\n explicitsystem_error(charconst*exp);\n\n unit_test::readonly_property<long>p_errno;\n unit_test::readonly_property<charconst*>p_failed_exp;\n};\n\n#defineBOOST_TEST_SYS_ASSERT(exp)if((exp));elsethrow::boost::system_error(BOOST_STRINGIZE(exp))\n\nnamespacefpe{\n\nenummasks{\n BOOST_FPE_OFF=0,\n\n#ifdefBOOST_SEH_BASED_SIGNAL_HANDLING\n BOOST_FPE_DIVBYZERO=EM_ZERODIVIDE,\n BOOST_FPE_INEXACT=EM_INEXACT,\n BOOST_FPE_INVALID=EM_INVALID,\n BOOST_FPE_OVERFLOW=EM_OVERFLOW,\n BOOST_FPE_UNDERFLOW=EM_UNDERFLOW|EM_DENORMAL,\n\n BOOST_FPE_ALL=MCW_EM,\n#elifdefined(BOOST_NO_FENV_H)||defined(BOOST_CLANG)\n BOOST_FPE_ALL=1,\n#else\n BOOST_FPE_DIVBYZERO=FE_DIVBYZERO,\n BOOST_FPE_INEXACT=FE_INEXACT,\n BOOST_FPE_INVALID=FE_INVALID,\n BOOST_FPE_OVERFLOW=FE_OVERFLOW,\n BOOST_FPE_UNDERFLOW=FE_UNDERFLOW,\n\n BOOST_FPE_ALL=FE_ALL_EXCEPT,\n#endif\n BOOST_FPE_INV=BOOST_FPE_ALL+1\n};\n\n// return the previous set of enabled exceptions when successful, and BOOST_FPE_INV otherwise\nunsignedBOOST_TEST_DECLenable(unsignedmask);\nunsignedBOOST_TEST_DECLdisable(unsignedmask);\n\n}// namespace fpe\n}// namespace boost\n
\n When performing an exception\n safety test, this argument forces a break into the debugger at\n the named exection path point within the test\n name. The test must be named exactly, no wildcards\n are supported.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Value\n
\n
\n
\n
\n Meaning\n
\n
\n
\n
\n
\n
\n name:path\n
\n
\n
\n
\n For test case name, break on execution\n path number path.\n
\n This argument causes the test runner to report information about the\n build environment before running the tests. If the argument is specified\n but no value is given, then a value of yes is assumed.\n
\n On systems that support colored text output, this argument controls whether\n or not the test runner will color the output. This argument does nothing\n on systems that do not support colored text output.\n
\n If the execution environment supoprts floating-point exceptions, this\n argument controls whether or not the test runner will detect floating-point\n exceptions.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Value\n
\n
\n
\n
\n Meaning\n
\n
\n
\n\n
\n
\n
\n no (default)\n
\n
\n
\n
\n Do not detect floating-point exceptions.\n
\n
\n
\n
\n
\n
\n yes\n
\n
\n
\n
\n Detect floating-point exceptions, if supported.\n
\n If the execution environment supports the detection of memory leaks,\n this argument controls whether or not the test runner reports memory\n leaks. After running the tests, a memory leak report is issued showing\n the allocation number and the amount of memory leaked.\n
\n
\n Values greater than 1 for this argument cause a trap\n to the debugger for a particular memory allocation number. Currently,\n this option is only implemented for Microsoft compilers.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Value\n
\n
\n
\n
\n Meaning\n
\n
\n
\n\n
\n
\n
\n 0\n
\n
\n
\n
\n Do not detect memory leaks.\n
\n
\n
\n
\n
\n
\n 1 (default)\n
\n
\n
\n
\n Detect memory leaks and issue a memory leak report.\n
\n This argument controls the level of test runner output. The values are\n cumulative, with each increase in log level including all messages at\n lower levels. By default, only errors are reported. See test\n runner log for more information on the log.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Value\n
\n
\n
\n
\n Meaning\n
\n
\n
\n\n
\n
\n
\n nothing\n
\n
\n
\n
\n Do not report any information.\n
\n
\n
\n
\n
\n
\n fatal_error\n
\n
\n
\n
\n Report all user or system fatal errors, such as memory access\n violation.\n
\n
\n
\n
\n
\n
\n system_error\n
\n
\n
\n
\n Report system non-fatal errors, such as timeout or floating-point\n exception.\n
\n This argument controls whether or not the test runner will execute tests\n in a random order. This argument can also provide a seed for the random\n number generator used to run tests in a random order.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Value\n
\n
\n
\n
\n Meaning\n
\n
\n
\n\n
\n
\n
\n 0 (default)\n
\n
\n
\n
\n Run tests in registration order.\n
\n
\n
\n
\n
\n
\n 1\n
\n
\n
\n
\n Run tests in a random order, using the current time as the\n seed.\n
\n
\n
\n
\n
\n
\n n\n
\n
\n
\n
\n Run tests in a random order, using n\n as the seed.\n
\n This argument controls the level of the test report. The levels are cumulative,\n with each successive level incorporating the output of all the previous\n levels.\n
\n This argument controls whether or not the test runner returns an exit\n code corresponding to a summary of the test execution or zero. The summary\n result code is determined as follows:\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Result Code\n
\n
\n
\n
\n Description\n
\n
\n
\n\n
\n
\n
\n 0 (boost::exit_success)\n
\n
\n
\n
\n All executed tests passed.\n
\n
\n
\n
\n
\n
\n 200 (boost::exit_exception_failure)\n
\n
\n
\n
\n Failure due to uncaught exception.\n
\n
\n
\n
\n
\n
\n 201 (boost::exit_test_failure)\n
\n
\n
\n
\n One or more executed tests failed.\n
\n
\n
\n\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Value\n
\n
\n
\n
\n Meaning\n
\n
\n
\n\n
\n
\n
\n no\n
\n
\n
\n
\n Always return zero.\n
\n
\n
\n
\n
\n
\n yes (default)\n
\n
\n
\n
\n Return a status code indicating the summary of the tests executed.\n
\n This argument informs the test runner of a boolean value used to create\n or save a test pattern for file-based testing. The test case uses the\n boolean value to determine whether or not it writes the test pattern\n by exercising the system under test or reads the test pattern for comparison\n against the values produced by the system under test. The output_test_stream\n class provides a facility for recording and matching against save patterns.\n
\n This parameter instructs the test runner to print progress through the\n test cases. The test runner has no way of determining the length of time\n each test case will consume; the progress percentage is determined by\n counting test cases.\n
\n This argument controls whether or not a debugger is attached to the test\n runner when a fatal system error occurs. A fatal system error includes\n Unix/POSIX signals, C++ exceptions and Win32 structured exceptions.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Value\n
\n
\n
\n
\n Meaning\n
\n
\n
\n\n
\n
\n
\n no (default)\n
\n
\n
\n
\n Do not attach a debugger to when a fatal system error occurs.\n
\n
\n
\n
\n
\n
\n yes\n
\n
\n
\n
\n Attach the default debugger when a fatal system error occurs.\n
\n This argument instructs the test runner to print out an indented listing\n of all test suites and test cases registered with the test runner without\n running the tests.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Value\n
\n
\n
\n
\n Meaning\n
\n
\n
\n\n
\n
\n
\n no (default)\n
\n
\n
\n
\n Do not list test suites and cases.\n
\n
\n
\n
\n
\n
\n yes\n
\n
\n
\n
\n List test suites and cases and exit without running tests.\n
\n This argument controls the format of the test runner output. The value\n is case insensitive. See test\n runner log for more information on the log.\n
\n This argument controls the level of test runner output. The values are\n cumulative, with each increase in log level including all messages at\n lower levels. By default, only errors are reported. See test\n runner log for more information on the log.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Value\n
\n
\n
\n
\n Meaning\n
\n
\n
\n\n
\n
\n
\n nothing\n
\n
\n
\n
\n Do not report any information.\n
\n
\n
\n
\n
\n
\n fatal_error\n
\n
\n
\n
\n Report all user or system fatal errors, such as memory access\n violation.\n
\n
\n
\n
\n
\n
\n system_error\n
\n
\n
\n
\n Report system non-fatal errors, such as timeout or floating-point\n exception.\n
\n This argument controls the level of the test report. The levels are cumulative,\n with each successive level incorporating the output of all the previous\n levels. See test\n runner report for more information on the report.\n
\n This argument controls which test cases will be executed. The value is\n a comma separated list of test specifiers. Test cases are arranged as\n leaves on a tree structure, with every test case belonging to a test\n suite. The test runner always creates a master test suite. Named test\n suites are children of the master test suite or another named test suite.\n Any test case that is not the child of a named test suite is a child\n of the unnamed master test suite.\n
\n
\n Test specifiers select test cases or suites by naming the path from the\n unnamed master test suite to the case or suite, similar to a full path\n to a file in a hierarchical directory structure. A test specifier is\n one or more path specifiers, separated by a slash (/).\n A test specifier begins at the master test suite and proceeds down the\n test tree, naming suites or test cases.\n
\n
\n The argument --report_level\n set to detailed can be used to output the names of\n all the test suites and test cases within those test suites.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Path Specifier\n
\n
\n
\n
\n Tests Selected\n
\n
\n
\n\n
\n
\n
\n name\n
\n
\n
\n
\n The test case or suite named name.\n
\n
\n
\n
\n
\n
\n *name\n
\n
\n
\n
\n All test cases or suites whose name ends in name.\n
\n
\n
\n
\n
\n
\n name*\n
\n
\n
\n
\n All test cases or suites whose name begins with name.\n
\n
\n
\n
\n
\n
\n *name*\n
\n
\n
\n
\n All test cases or suites whose name contains name.\n
\n
\n
\n
\n
\n
\n *\n
\n
\n
\n
\n All test cases or suites.\n
\n
\n
\n
\n
\n
\n spec1,spec2,...\n
\n
\n
\n
\n The test cases or suites with the given specifier.\n
\n
\n
\n
\n
\n
\n spec1/spec2\n
\n
\n
\n
\n The test cases or suites matched by spec2\n in the test suite matched by spec1.\n
\n Automatically attach debugger in case of system failure\n
\n
\n
\n
\n
\n
\n --build_info\n
\n
\n
\n
\n Print build information\n
\n
\n
\n
\n
\n
\n --catch_system_errors\n
\n
\n
\n
\n Catch system errors\n
\n
\n
\n
\n
\n
\n --detect_fp_exceptions\n
\n
\n
\n
\n Detect floating-point exceptions\n
\n
\n
\n
\n
\n
\n --detect_memory_leaks\n
\n
\n
\n
\n Detect memory leaks\n
\n
\n
\n
\n
\n
\n --help\n
\n
\n
\n
\n Print out a summary of test runner options\n
\n
\n
\n
\n
\n
\n --log_format\n
\n
\n
\n
\n The format of the test log\n
\n
\n
\n
\n
\n
\n --log_level\n
\n
\n
\n
\n The level of logging reported\n
\n
\n
\n
\n
\n
\n --log_sink\n
\n
\n
\n
\n The log sink name\n
\n
\n
\n
\n
\n
\n --output_format\n
\n
\n
\n
\n The output format\n
\n
\n
\n
\n
\n
\n --random\n
\n
\n
\n
\n Random number seed\n
\n
\n
\n
\n
\n
\n --report_format\n
\n
\n
\n
\n The test results report format\n
\n
\n
\n
\n
\n
\n --report_level\n
\n
\n
\n
\n The test results report level\n
\n
\n
\n
\n
\n
\n --report_sink\n
\n
\n
\n
\n The report sink name\n
\n
\n
\n
\n
\n
\n --result_code\n
\n
\n
\n
\n Return result code\n
\n
\n
\n
\n
\n
\n --run_test\n
\n
\n
\n
\n Tests to run\n
\n
\n
\n
\n
\n
\n --show_progress\n
\n
\n
\n
\n Show execution progress\n
\n
\n
\n
\n
\n
\n --use_alt_stack\n
\n
\n
\n
\n Use alternative stack\n
\n
\n
\n
\n
\n
\n --wait_for_debugger\n
\n
\n
\n
\n Wait for the debugger to attach to the test runner.\n
\n
\n
\n\n
\n
\n
\n The functionality of each command-line option can also be invoked with\n an environment variable. The description for each option gives the environment\n variable associated with that option.\n
\n BOOST_TEST_CHECKPOINT(message)\n registers a test case checkpoint and associated message\n with the test runner. A checkpoint includes the source file and line\n number where the macro was invoked. If the test case is aborted unexpectedly,\n the source location and message associated with the last registered checkpoint\n is emitted into the log. Checkpoints can be used to identify the location\n of an unexpected failure within a block of test case code. The message\n is applied to an output stream with operator<< and can include other invocations\n of operator<<.\n
\n BOOST_TEST_CHECKPOINT(message)\n registers a test case checkpoint and associated message\n with the test runner. A checkpoint includes the source file and line\n number where the macro was invoked. If the test case is aborted unexpectedly,\n the source location and message associated with the last registered checkpoint\n is emitted into the log. Checkpoints can be used to identify the location\n of an unexpected failure within a block of test case code. The message\n is applied to an output stream with operator<< and can include other invocations\n of operator<<.\n
\n BOOST_TEST_MESSAGE(message)\n unconditionally writes the message into the\n test runner log file. Unlike BOOST_TEST_CHECKPOINT\n no file and line number information is written into the log file. The\n message is applied to an output stream with\n operator<<\n and can include other invocations of operator<<.\n
\n The test log contains detailed information on every assertion in every\n test case. The log can be formatted as plain human readable text or as\n XML and can be sent to the standard output stream, the standard error\n stream or a file.\n
\n
\n The amount of detail in the log is set with the --log_level\n option. The format of the log is set with the --log_format\n option. The destination of the log is set with the --log_sink\n option. The --output_format\n option sets both the log format and the report format.\n
\n
\n The XML format for the test log conforms to the schema UTF.log.xsd.\n
\n The report contains summary information about the test cases executed\n and the count of failures. The report can be formatted as plain human\n readable text or as XML and can be sent to the standard output stream,\n standard error stream or a file.\n
\n
\n The amount of detail in the report is controlled by the --report_level\n option. The format of the report can be changed with the --report_format\n option. The destination of the report can be set with the --report_sink\n option. The --output_format\n option sets both the report format and the log format.\n
\n
\n The XML format for the test report conforms to the schema UTF.report.xsd.\n
\n BOOST_AUTO_TEST_CASE(name)\n creates a test case class, a test case invocation function, a test case\n unique identifier, registers the invocation function as a test case and\n begins the definition of the test method on the test class. The test case\n class name is derived from BOOST_AUTO_TEST_CASE_FIXTURE\n and contains a single method named test_method. The\n test invocation function instantiates the test case class and invokes the\n test case method. Test log checkpoints are made before the test case class\n is instantiated and bracketing the test method invocation. This provides\n diagnostic checkpoints should a runtime error cause a test case to be aborted\n before any assertions are made.\n
\n BOOST_AUTO_TEST_CASE_EXPECTED_FAILURES(name,\n n) is used to decorate a\n test case with an expected failure count of n.\n It should appear immediately preceding the macro that defines the test\n case, such as BOOST_AUTO_TEST_CASE\n or BOOST_FIXTURE_TEST_CASE.\n It can be used for test cases declared at file scope or within a test suite.\n This macro should only be used in the most exceptional of circumstances.\n Unit tests are designed to provide a safety net of regression tests against\n our code. If we allow tests to stay failing, we are less motivated to correct\n them.\n
\n
\n As a temporary measure, we may wish to annotate certain tests as known\n failures. The count n is the number of expected\n failed assertions during the execution of the test case. When using the\n CHECK\n level assertions, the total failure count can be larger than one since\n the test case continues executing past a failed assertion. When using\n REQUIRE level assertions, the total failure count will\n only be one as execution of the test case terminates on the first failed\n assertion.\n
\n
\n If CHECK level assertions are used and the number of\n failures is less than or equal to n, the test\n runner will return a status code of 0. If the number\n of failures is greather than n, the test runner\n will return a status code of 201. If REQUIRE\n level assertions are used, the number of expected failures can be at most\n one and the test runner will return a status code of 200\n when one failed assertion is found.\n
\n When using the compiler formatted test output, Visual Studio interprets\n the failed assertion output as a detected error, it will fail the Post-Build\n event mechanism recommended in Test\n Case Design and Maintenance.\n
\n BOOST_AUTO_TEST_CASE_TEMPLATE(name,\n var, types)\n declares a test case name parameterized by a\n single template argument var that is evaluated\n for each type in types. This allows you to write\n a test case that exercises an invariant across a collection of types. The\n macro expands into one test case for each type in types,\n with the template argument var assigned to each\n type. The types argument must be a Boost.MPL\n type list and must be defined as a typedef.\n
\n BOOST_FIXTURE_TEST_CASE(name,\n fixture) defines a test case\n class name that derives from fixture.\n If the test case is declared within a test suite that also has a test fixture,\n then to get the cumulative effect of both fixtures the test case fixture\n should derive from the test suite's fixture. Otherwise, the test case fixture\n will replace the test suite fixture for a test case defined with BOOST_FIXTURE_TEST_CASE.\n
\n BOOST_GLOBAL_FIXTURE(name)\n declares a global fixture that is constructed before executing any test\n cases and is destroyed after executing all test cases. If more than one\n global fixture is defined in a single source file, the fixtures are constructed\n in the order they appear in the source file and destroyed in the reverse\n order. If global fixtures are defined in multiple source files, the order\n in which global fixtures are initialized between source files is implementation\n dependent.\n
\n
\n Because global fixtures are not created and destroyed for each test case,\n they represent shared state that prevents test cases from executing independently\n from each other. For this reason, test case fixtures created with BOOST_FIXTURE_TEST_CASE\n and test suite fixtures created with BOOST_FIXTURE_TEST_SUITE\n are preferred over global fixtures.\n
\n BOOST_PARAM_CLASS_TEST_CASE(memfn,\n instance, begin,\n end) works similarly to\n BOOST_PARAM_TEST_CASE.\n It creates a collection of test cases that invoke the member function\n memfn on the instance pointer instance.\n The member function is passed an item obtained by iterating the collection\n defined by the begin and end\n iterators. The instance pointer must be passed\n as a boost::shared_ptr to ensure the lifetime of the\n instance exceeds that of any test case using the instance. The test case\n returned by BOOST_PARAM_CLASS_TEST_CASE must be added\n to a test suite in an initialization function for the tests to be executed.\n
\n The single instance is shared among all test\n cases and therefore should not keep any shared state that may couple\n independent test cases. In this example, the output string stream is\n created fresh inside each test method and not shared between calls to\n the method.\n
\n BOOST_PARAM_TEST_CASE(fn,\n begin, end)\n creates a series of test cases that invoking the callable object fn\n on the items in the collection defined by begin\n and end. The test case returned by BOOST_PARAM_TEST_CASE\n must be added to a test suite in an initialization function for the tests\n to be executed. The iterators begin and end\n must be valid at the time the test case executes and not just at the time\n the test case is created.\n
\n BOOST_TEST_CASE(fn)\n creates a new test case named \"fn\" that executes the callable\n function fn. The test case returned by BOOST_TEST_CASE\n must be added to a test suite in an initialization function for the tests\n to be executed.\n
\n BOOST_TEST_CASE_TEMPLATE(name,\n types) manually creates a\n set of test cases from the template test case name\n for each type in types. The test case returned\n by BOOST_TEST_CASE_TEMPLATE must be added to a test\n suite in an initialization function for the tests to be executed. The test\n case function is defined with the BOOST_TEST_CASE_TEMPLATE_FUNCTION\n macro.\n
\n BOOST_TEST_CASE_TEMPLATE_FUNCTION(name,\n T) defines a test case function\n named name that is parameterized by a type parameter\n T. The defined functions are then available\n for registration as parameterized test cases with BOOST_TEST_CASE_TEMPLATE.\n
\n A test case is a named body of code providing the three phases of a test:\n setup, exercise and verify. A test case is most conveniently created using\n one of the provided test case macros listed in the following table.\n
\n
\n
Table 1.1. Test Case Macros
\n
\n
\n
\n
\n
\n
\n
\n
\n Macro\n
\n
\n
\n
\n Description\n
\n
\n
\n\n
\n
\n
\n BOOST_AUTO_TEST_CASE(name)\n
\n
\n
\n
\n Creates test case name and automatically\n registers it with the test runner.\n
\n Manually creates a parameterized test case using the supplied callable\n object fn, class instance instance\n and parameter iterators begin and end.\n
\n
\n
\n
\n
\n
\n BOOST_TEST_CASE(fn)\n
\n
\n
\n
\n Manually creates a test case using the supplied callable object\n fn.\n
\n
\n
\n
\n
\n
\n BOOST_TEST_CASE_TEMPLATE(name,\n types)\n
\n
\n
\n
\n Manually creates a set of test cases from the template test case\n name for each type in types.\n
\n
\n
\n
\n
\n
\n BOOST_TEST_CASE_TEMPLATE_FUNCTION(name,\n T)\n
\n
\n
\n
\n Manually creates a template test case name\n parameterized by the template argument T.\n
\n BITWISE_level_EQUAL(lhs,\n rhs) compares the two arguments\n for bitwise equality and fails if they are not equal. This can be useful\n when testing integral values that represent a logical or combination\n of bit flags.\n
\n BOOST_level_CLOSE(lhs,\n rhs, tolerance)\n compares the two floating-point arguments and considers them equal if\n they agree within the given tolerance. The\n tolerance is given as a percentage.\n
\n BOOST_level_CLOSE_FRACTION(lhs,\n rhs, tolerance)\n compares the two floating-point arguments and considers them equal if\n they agree within the given tolerance. The\n tolerance is given as a percentage.\n
\n BOOST_level=_EQUAL_COLLECTIONS(lhs_begin,\n lhs_end, rhs_begin,\n rhs_end) compares two collections\n for equality. Two collections are considered equal if they have the same\n number of elements and the elements compare equal by operator==. The elements are obtained through\n the supplied iterators on the collections. The diagnostic message is\n constructed from applying operator<< to each of the elements in the\n collections.\n
\n
\n
\n
\n
Important
\n
\n
\n If you get a strange compile error when using BOOST_EQUAL_COLLECTIONS,\n check that the appropriate operator== and operator<< are defined for the element\n type in the collection. If you define these operators in your test\n code, keep in mind argument-dependent lookup of types based on enclosing\n namespaces and the namespaces opened by test suites.\n
\n BOOST_level_EXCEPTION(statement,\n exception, predicate)\n asserts that when statement throws an exception\n of type exception, the predicate\n applied to the instance of the exception returns true.\n This is used to verify not only that an exception of the correct type\n was thrown, but that the contents of the thrown exception meet the expectations\n of the predicate.\n
\n BOOST_level_GE(lhs,\n rhs) asserts that lhs\n is greater than or equal to rhs. The comparison\n is made by applying operator>= to both arguments. The diagnostic\n message is constructed from applying operator<< to the two arguments.\n
\n
\n
\n
\n
Important
\n
\n
\n If you get a strange compile error when using BOOST_level_GE,\n check that the appropriate operator>= and operator<< are defined for the arguments.\n If you define these operators in your test code, keep in mind argument-dependent\n lookup of types based on enclosing namespaces and the namespaces opened\n by test suites.\n
\n
\n
\n
\n
BOOST_AUTO_TEST_CASE(example_ge)\n{\n // integral types\n unsignedconstu=1u;\n intconsti=-10;\n charconstA='A';\n // standard library types providing operator>= and operator<<\n std::stringconsts=\"scooby\";\n\n BOOST_REQUIRE_GE(2u,u);\n BOOST_REQUIRE_GE(1u,u);\n BOOST_REQUIRE_GE(-9,i);\n BOOST_REQUIRE_GE(-10,i);\n BOOST_REQUIRE_GE('B',A);\n BOOST_REQUIRE_GE('A',A);\n BOOST_REQUIRE_GE(\"scoobz\",s);\n BOOST_REQUIRE_GE(\"scooby\",s);\n}\n
\n BOOST_level_GT(lhs,\n rhs) asserts that lhs\n is greater than rhs. The comparison is made\n by applying operator>\n to both arguments. The diagnostic message is constructed from applying\n operator<<\n to the two arguments.\n
\n
\n
\n
\n
Important
\n
\n
\n If you get a strange compile error when using BOOST_level_GT,\n check that the appropriate operator> and operator<< are defined for the arguments.\n If you define these operators in your test code, keep in mind argument-dependent\n lookup of types based on enclosing namespaces and the namespaces opened\n by test suites.\n
\n
\n
\n
\n
BOOST_AUTO_TEST_CASE(example_gt)\n{\n // integral types\n unsignedconstu=1u;\n intconsti=-10;\n charconstA='A';\n // standard library types providing operator> and operator==\n std::stringconsts=\"scooby\";\n\n BOOST_REQUIRE_GT(2u,u);\n BOOST_REQUIRE_GT(-9,i);\n BOOST_REQUIRE_GT('B',A);\n BOOST_REQUIRE_GT(\"scoobz\",s);\n}\n
\n BOOST_level_LE(lhs,\n rhs) asserts that lhs\n is less than or equal to rhs. The comparison\n is made by applying operator<= to both arguments. The diagnostic\n message is constructed from applying operator<< to the two arguments.\n
\n
\n
\n
\n
Important
\n
\n
\n If you get a strange compile error when using BOOST_level_LE,\n check that the appropriate operator<= and operator<< are defined for the arguments.\n If you define these operators in your test code, keep in mind argument-dependent\n lookup of types based on enclosing namespaces and the namespaces opened\n by test suites.\n
\n
\n
\n
\n
BOOST_AUTO_TEST_CASE(example_le)\n{\n // integral types\n unsignedconstu=10u;\n intconsti=-10;\n charconstM='M';\n // standard library types providing operator>= and operator<<\n std::stringconsts=\"scooby\";\n\n BOOST_REQUIRE_LE(9u,u);\n BOOST_REQUIRE_LE(10u,u);\n BOOST_REQUIRE_LE(-11,i);\n BOOST_REQUIRE_LE(-10,i);\n BOOST_REQUIRE_LE('L',M);\n BOOST_REQUIRE_LE('M',M);\n BOOST_REQUIRE_LE(\"scoobx\",s);\n BOOST_REQUIRE_LE(\"scooby\",s);\n}\n
\n BOOST_level_LT(lhs,\n rhs) asserts that lhs\n is less than rhs. The comparison is made by\n applying operator<\n to both arguments. The diagnostic message is constructed from applying\n operator<<\n to the two arguments.\n
\n
\n
\n
\n
Important
\n
\n
\n If you get a strange compile error when using BOOST_level_LT,\n check that the appropriate operator< and operator<< are defined for the arguments.\n If you define these operators in your test code, keep in mind argument-dependent\n lookup of types based on enclosing namespaces and the namespaces opened\n by test suites.\n
\n
\n
\n
\n
BOOST_AUTO_TEST_CASE(example_lt)\n{\n // integral types\n unsignedconstu=10u;\n intconsti=-10;\n charconstM='M';\n // standard library types providing operator>= and operator<<\n std::stringconsts=\"scooby\";\n\n BOOST_REQUIRE_LT(9u,u);\n BOOST_REQUIRE_LT(-11,i);\n BOOST_REQUIRE_LT('L',M);\n BOOST_REQUIRE_LT(\"scoobx\",s);\n}\n
\n BOOST_level_MESSAGE(predicate,\n message) emits message\n if the supplied predicate evaluates to false.\n The message is applied to an output stream\n with operator<<\n and the argument can contain additional applications of operator<<\n for building up complex messages. The predicate can return bool\n or __predicate_result__.\n
\n
\n
\n
staticintg_i;\n\n// simple predicate\nstaticboolglobal_int_is_positive()\n{\n returng_i>0;\n}\n\n// predicate that builds up detail message\nstaticboost::test_tools::predicate_resultglobal_int_equal(intexpected)\n{\n if(g_i==expected)\n {\n returntrue;\n }\n\n boost::test_tools::predicate_resultfailed=false;\n failed.message()<<\"g_i != \"<<expected<<\"; actual: \"<<g_i;\n returnfailed;\n}\n\nBOOST_AUTO_TEST_CASE(example_message)\n{\n g_i=1;\n\n BOOST_REQUIRE_MESSAGE(global_int_is_positive(),\n \"g_i is not positive; actual: \"<<g_i);\n BOOST_REQUIRE_MESSAGE(global_int_equal(1),\"\");\n}\n
\n BOOST_level_NE(lhs,\n rhs) asserts that lhs\n is not equal to rhs. The comparison is made\n by applying operator!=\n to both arguments. The diagnostic message is constructed from applying\n operator<<\n to the two arguments.\n
\n
\n
\n
\n
Important
\n
\n
\n If you get a strange compile error when using BOOST_level_NE,\n check that the appropriate operator!= and operator<< are defined for the arguments.\n If you define these operators in your test code, keep in mind argument-dependent\n lookup of types based on enclosing namespaces and the namespaces opened\n by test suites.\n
\n BOOST_TEST_DONT_PRINT_LOG_VALUE(type)\n instructs the test framework to ignore values of type type\n when constructing diagnostic messages. It does this by defining an empty\n implementation of a print function specialized for type.\n
\n BOOST_EQUAL(lhs, rhs)\n compares the two arguments with operator==. The diagnostic message is constructed\n with operator<<\n on the two arguments.\n
\n
\n
\n
\n
Important
\n
\n
\n If you get a strange compile error when using BOOST_EQUAL\n check that the appropriate operator== and operator<< are defined for the arguments.\n If you define these operators in your test code, keep in mind argument-dependent\n lookup of types based on enclosing namespaces and the namespaces opened\n by test suites.\n
\n
\n
\n
\n
BOOST_AUTO_TEST_CASE(example_equal)\n{\n // integral types\n unsignedconstu=1u;\n intconsti=-1;\n charconstA='A';\n // standard library types providing operator== and operator<<\n std::stringconsts=\"scooby\";\n\n BOOST_REQUIRE_EQUAL(1u,u);\n BOOST_REQUIRE_EQUAL(-1,i);\n BOOST_REQUIRE_EQUAL('A',A);\n BOOST_REQUIRE_EQUAL(\"scooby\",s);\n}\n
\n When using the library or header-only version of Boost.Test, many assertion\n macros are provided in three levels that determine the behavior when\n the assertion fails and how a failed assertion interacts with the test\n runner.\n
\n
\n
Table 1.2. Assertion Levels
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Level\n
\n
\n
\n
\n Test Case Fails?\n
\n
\n
\n
\n Aborts Execution?\n
\n
\n
\n\n
\n
\n
\n WARN\n
\n
\n
\n
\n No\n
\n
\n
\n
\n No\n
\n
\n
\n
\n
\n
\n CHECK\n
\n
\n
\n
\n Yes\n
\n
\n
\n
\n no\n
\n
\n
\n
\n
\n
\n REQUIRE\n
\n
\n
\n
\n Yes\n
\n
\n
\n
\n Yes\n
\n
\n
\n\n
\n
\n
\n The WARN level issues a diagnostic message, but the\n test case is not considered to have failed and continues executing. The\n CHECK level issues a message to the test log on failure,\n marks the test case as failed and continues executing. The REQUIRE\n level issues a message to the test log on failure, marks the test case\n as failed and halts execution of the test case.\n
\n Assertions are used to validate the result of exercising the system under\n test. When an assertion fails, a diagnostic message is created and the\n failed assertion is recorded. Different assertion levels allow you to control\n how a failed assertion is interpreted by the test runner.\n
\n
\n
\n
\n
Important
\n
\n
\n When an assertion involves a user-defined datatype, a stream insertion\n operator (operator<<)\n must be defined for the user-defined datatype, or the assertion will\n fail to compile. Asserting a comparison operation on a value of a user-defined\n type will require the appropriate comparison operator (operator<,\n operator==,\n etc.) be defiend for the type or the assertion will fail to compile.\n
\n
\n
\n The minimal header\n test framework does not provide the facilities described here.\n
namespaceboost{\n\nclassexecution_exception{\n typedefboost::unit_test::const_stringconst_string;\npublic:\n enumerror_code{\n no_error=0,\n user_error=200,\n cpp_exception_error=205,\n system_error=210,\n timeout_error=215,\n user_fatal_error=220,\n system_fatal_error=225\n };\n\n structBOOST_TEST_DECLlocation{\n explicitlocation(charconst*file_name=0,size_tline_num=0,charconst*func=0);\n\n const_stringm_file_name;\n size_tm_line_num;\n const_stringm_function;\n };\n\n // Constructor\n execution_exception(error_codeec_,const_stringwhat_msg_,locationconst&location_);// max length 256 inc '\\0'\n\n // Access methods\n error_codecode()const{returnm_error_code;}\n const_stringwhat()const{returnm_what;}\n locationconst&where()const{returnm_location;}\n};// execution_exception\n\nclassexecution_monitor{\n typedefboost::unit_test::const_stringconst_string;\npublic:\n execution_monitor();\n\n // Public properties\n\n // The p_catch_system_errors parameter specifies whether the monitor should \n // try to catch system errors/exceptions that would cause program to crash \n // in regular case\n unit_test::readwrite_property<bool>p_catch_system_errors;\n\n // The p_auto_start_dbg parameter specifies whether the monitor should \n // try to attach debugger in case of caught system error\n unit_test::readwrite_property<bool>p_auto_start_dbg;\n\n // The p_timeout parameter specifies the seconds that elapse before\n // a timer_error occurs. May be ignored on some platforms.\n unit_test::readwrite_property<int>p_timeout;\n\n // The p_use_alt_stack parameter specifies whether the monitor should\n // use alternative stack for the signal catching\n unit_test::readwrite_property<bool>p_use_alt_stack;\n\n // The p_detect_fp_exceptions parameter specifies whether the monitor should\n // try to detect hardware floating point exceptions (!= 0), and which specific exception to catch\n unit_test::readwrite_property<unsigned>p_detect_fp_exceptions;\n\n intexecute(boost::function<int()>const&F);\n // Returns: Value returned by function call F().\n //\n // Effects: Calls executes supplied function F inside a try/catch block which also may\n // include other unspecified platform dependent error detection code.\n //\n // Throws: execution_exception on an uncaught C++ exception,\n // a hardware or software signal, trap, or other exception.\n //\n // Note: execute() doesn't consider it an error for F to return a non-zero value.\n\n voidvexecute(boost::function<void()>const&F);\n // Effects: Same as above, but returns nothing\n\n // register custom (user supplied) exception translator\n template<typenameExceptionType,typenameExceptionTranslator>\n voidregister_exception_translator(ExceptionTranslatorconst&tr,const_stringtag=const_string(),boost::type<ExceptionType>*=0);\n\n // erase custom exception translator\n voiderase_exception_translator(const_stringtag)\n {\n m_custom_translators=m_custom_translators->erase(m_custom_translators,tag);\n }\n template<typenameExceptionType>\n voiderase_exception_translator(boost::type<ExceptionType>*=0)\n {\n m_custom_translators=m_custom_translators->erase<ExceptionType>(m_custom_translators);\n }\n\n};// execution_monitor\n\ntemplate<typenameExceptionType,typenameExceptionTranslator>\nvoid\nexecution_monitor::register_exception_translator(ExceptionTranslatorconst&tr,const_stringtag,boost::type<ExceptionType>*)\n{\n m_custom_translators.reset(\n newdetail::translator_holder<ExceptionType,ExceptionTranslator>(tr,m_custom_translators,tag));\n}\n\nstructexecution_aborted{};\n\nclasssystem_error{\npublic:\n // Constructor\n explicitsystem_error(charconst*exp);\n\n unit_test::readonly_property<long>p_errno;\n unit_test::readonly_property<charconst*>p_failed_exp;\n};\n\n#defineBOOST_TEST_SYS_ASSERT(exp)if((exp));elsethrow::boost::system_error(BOOST_STRINGIZE(exp))\n\nnamespacefpe{\n\nenummasks{\n BOOST_FPE_OFF=0,\n\n#ifdefBOOST_SEH_BASED_SIGNAL_HANDLING\n BOOST_FPE_DIVBYZERO=EM_ZERODIVIDE,\n BOOST_FPE_INEXACT=EM_INEXACT,\n BOOST_FPE_INVALID=EM_INVALID,\n BOOST_FPE_OVERFLOW=EM_OVERFLOW,\n BOOST_FPE_UNDERFLOW=EM_UNDERFLOW|EM_DENORMAL,\n\n BOOST_FPE_ALL=MCW_EM,\n#elifdefined(BOOST_NO_FENV_H)||defined(BOOST_CLANG)\n BOOST_FPE_ALL=1,\n#else\n BOOST_FPE_DIVBYZERO=FE_DIVBYZERO,\n BOOST_FPE_INEXACT=FE_INEXACT,\n BOOST_FPE_INVALID=FE_INVALID,\n BOOST_FPE_OVERFLOW=FE_OVERFLOW,\n BOOST_FPE_UNDERFLOW=FE_UNDERFLOW,\n\n BOOST_FPE_ALL=FE_ALL_EXCEPT,\n#endif\n BOOST_FPE_INV=BOOST_FPE_ALL+1\n};\n\n// return the previous set of enabled exceptions when successful, and BOOST_FPE_INV otherwise\nunsignedBOOST_TEST_DECLenable(unsignedmask);\nunsignedBOOST_TEST_DECLdisable(unsignedmask);\n\n}// namespace fpe\n}// namespace boost\n
\n The init_unit_test_func function typedef identifies\n the signature of the user supplied initialization function. The initialization\n function can be used to add custom test cases and test suites to the test\n tree.\n
\n The init_unit_test_func function typedef identifies\n the signature of the user supplied initialization function. The initialization\n function can be used to add custom test cases and test suites to the\n test tree.\n
\n The test_case class represents a single test case.\n A test case must be added to a test suite reachable from the master test\n suite in order for the test runner to run the test case.\n
\n The test_unit class forms the basis of the hierarchical\n tree of test cases. Test applications will usually create instances of\n test_case or test_suite, both of\n which derive from test_unit.\n
\n
\n
\n
namespaceboost{namespaceunit_test{\n\nclassBOOST_TEST_DECLtest_unit{\npublic:\n enum{type=tut_any};\n\n // Constructor\n test_unit(const_stringtu_name,test_unit_typet);\n\n // dependencies management\n voiddepends_on(test_unit*tu);\n boolcheck_dependencies()const;\n\n // Public r/o properties\n typedefBOOST_READONLY_PROPERTY(test_unit_id,(framework_impl))id_t;\n typedefBOOST_READONLY_PROPERTY(test_unit_id,(test_suite))parent_id_t;\n readonly_property<test_unit_type>p_type;// type for this test unit\n readonly_property<const_string>p_type_name;// \"case\"/\"suite\"\n id_tp_id;// unique id for this test unit\n parent_id_tp_parent_id;// parent test suite id\n\n // Public r/w properties\n readwrite_property<std::string>p_name;// name for this test unit\n readwrite_property<unsigned>p_timeout;// timeout for the test unit execution\n readwrite_property<counter_t>p_expected_failures;// number of expected failures in this test unit\n mutablereadwrite_property<bool>p_enabled;// enabled status for this unit\n\n voidincrease_exp_fail(unsignednum);\n\n};\n\n}}\n
\n The unit_test_log_t class encapsulates the unit test\n log. You obtain a reference to the single global unit test log instance\n with the unit_test_log member.\n
\n unit_test_main initializes the test framework, traverses\n the test tree and reports the result as a the return value of the function.\n Unexpected exceptions and system errors (signals, etc.) are caught and\n mapped to appropriate return values by the function.\n
\n The predicate_result class combines a boolean result\n from a predicate with a detailed context message for a failed predicate\n evaluation. Usually this class is only used in the internal implementation\n of the test framework, but a user can define their own custom predicates\n that return a predicate_result to support detailed failure\n messages when an assertion fails.\n
\n
\n predicate_result is constructable and assignable from\n bool. The message() method returns\n an output string stream that can be used to build up a context message.\n
\n Automatically attach debugger in case of system failure\n
\n
\n
\n
\n
\n
\n --break_exec_path\n
\n
\n
\n
\n Break execution path\n
\n
\n
\n
\n
\n
\n --build_info\n
\n
\n
\n
\n Print build information\n
\n
\n
\n
\n
\n
\n --catch_system_errors\n
\n
\n
\n
\n Catch system errors\n
\n
\n
\n
\n
\n
\n --color_output\n
\n
\n
\n
\n Produce color output\n
\n
\n
\n
\n
\n
\n --detect_fp_exceptions\n
\n
\n
\n
\n Detect floating-point exceptions\n
\n
\n
\n
\n
\n
\n --detect_memory_leaks\n
\n
\n
\n
\n Detect memory leaks\n
\n
\n
\n
\n
\n
\n --help\n
\n
\n
\n
\n Print out a summary of test runner options\n
\n
\n
\n
\n
\n
\n --log_format\n
\n
\n
\n
\n The format of the test log\n
\n
\n
\n
\n
\n
\n --log_level\n
\n
\n
\n
\n The level of logging reported\n
\n
\n
\n
\n
\n
\n --log_sink\n
\n
\n
\n
\n The log sink name\n
\n
\n
\n
\n
\n
\n --output_format\n
\n
\n
\n
\n The output format\n
\n
\n
\n
\n
\n
\n --random\n
\n
\n
\n
\n Random number seed\n
\n
\n
\n
\n
\n
\n --report_format\n
\n
\n
\n
\n The test results report format\n
\n
\n
\n
\n
\n
\n --report_level\n
\n
\n
\n
\n The test results report level\n
\n
\n
\n
\n
\n
\n --report_sink\n
\n
\n
\n
\n The report sink name\n
\n
\n
\n
\n
\n
\n --result_code\n
\n
\n
\n
\n Return result code\n
\n
\n
\n
\n
\n
\n --run_test\n
\n
\n
\n
\n Tests to run\n
\n
\n
\n
\n
\n
\n --save_pattern\n
\n
\n
\n
\n Save pattern\n
\n
\n
\n
\n
\n
\n --show_progress\n
\n
\n
\n
\n Show execution progress\n
\n
\n
\n
\n
\n
\n --use_alt_stack\n
\n
\n
\n
\n Use alternative stack\n
\n
\n
\n
\n
\n
\n --wait_for_debugger\n
\n
\n
\n
\n Wait for the debugger to attach to the test runner.\n
\n
\n
\n\n
\n
\n
\n The functionality of each command-line option can also be invoked with\n an environment variable. The description for each option gives the environment\n variable associated with that option.\n
\n This argument controls whether or not a debugger is attached to the\n test runner when a fatal system error occurs. A fatal system error\n includes Unix/POSIX signals, C++ exceptions and Win32 structured exceptions.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Value\n
\n
\n
\n
\n Meaning\n
\n
\n
\n\n
\n
\n
\n no (default)\n
\n
\n
\n
\n Do not attach a debugger to when a fatal system error occurs.\n
\n
\n
\n
\n
\n
\n yes\n
\n
\n
\n
\n Attach the default debugger when a fatal system error occurs.\n
\n When performing an exception safety test, this argument forces a break\n into the debugger at the named exection path\n point within the test name. The test must\n be named exactly, no wildcards are supported.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Value\n
\n
\n
\n
\n Meaning\n
\n
\n
\n
\n
\n
\n name:path\n
\n
\n
\n
\n For test case name, break on execution\n path number path.\n
\n This argument causes the test runner to report information about the\n build environment before running the tests. If the argument is specified\n but no value is given, then a value of yes is assumed.\n
\n On systems that support colored text output, this argument controls\n whether or not the test runner will color the output. This argument\n does nothing on systems that do not support colored text output.\n
\n If the execution environment supoprts floating-point exceptions, this\n argument controls whether or not the test runner will detect floating-point\n exceptions.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Value\n
\n
\n
\n
\n Meaning\n
\n
\n
\n\n
\n
\n
\n no (default)\n
\n
\n
\n
\n Do not detect floating-point exceptions.\n
\n
\n
\n
\n
\n
\n yes\n
\n
\n
\n
\n Detect floating-point exceptions, if supported.\n
\n If the execution environment supports the detection of memory leaks,\n this argument controls whether or not the test runner reports memory\n leaks. After running the tests, a memory leak report is issued showing\n the allocation number and the amount of memory leaked.\n
\n
\n Values greater than 1 for this argument cause a\n trap to the debugger for a particular memory allocation number. Currently,\n this option is only implemented for Microsoft compilers.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Value\n
\n
\n
\n
\n Meaning\n
\n
\n
\n\n
\n
\n
\n 0\n
\n
\n
\n
\n Do not detect memory leaks.\n
\n
\n
\n
\n
\n
\n 1 (default)\n
\n
\n
\n
\n Detect memory leaks and issue a memory leak report.\n
\n This argument controls the level of test runner output. The values\n are cumulative, with each increase in log level including all messages\n at lower levels. By default, only errors are reported.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Value\n
\n
\n
\n
\n Meaning\n
\n
\n
\n\n
\n
\n
\n nothing\n
\n
\n
\n
\n Do not report any information.\n
\n
\n
\n
\n
\n
\n fatal_error\n
\n
\n
\n
\n Report all user or system fatal errors, such as memory access\n violation.\n
\n
\n
\n
\n
\n
\n system_error\n
\n
\n
\n
\n Report system non-fatal errors, such as timeout or floating-point\n exception.\n
\n This argument controls whether or not the test runner will execute\n tests in a random order. This argument can also provide a seed for\n the random number generator used to run tests in a random order.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Value\n
\n
\n
\n
\n Meaning\n
\n
\n
\n\n
\n
\n
\n 0 (default)\n
\n
\n
\n
\n Run tests in registration order.\n
\n
\n
\n
\n
\n
\n 1\n
\n
\n
\n
\n Run tests in a random order, using the current time as the\n seed.\n
\n
\n
\n
\n
\n
\n n\n
\n
\n
\n
\n Run tests in a random order, using n\n as the seed.\n
\n This argument controls the level of the test report. The levels are\n cumulative, with each successive level incorporating the output of\n all the previous levels.\n
\n This argument controls whether or not the test runner returns an exit\n code corresponding to a summary of the test execution or zero. The\n summary result code is determined as follows:\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Result Code\n
\n
\n
\n
\n Description\n
\n
\n
\n\n
\n
\n
\n 0 (boost::exit_success)\n
\n
\n
\n
\n All executed tests passed.\n
\n
\n
\n
\n
\n
\n 200 (boost::exit_exception_failure)\n
\n
\n
\n
\n Failure due to uncaught exception.\n
\n
\n
\n
\n
\n
\n 201 (boost::exit_test_failure)\n
\n
\n
\n
\n One or more executed tests failed.\n
\n
\n
\n\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Value\n
\n
\n
\n
\n Meaning\n
\n
\n
\n\n
\n
\n
\n no\n
\n
\n
\n
\n Always return zero.\n
\n
\n
\n
\n
\n
\n yes (default)\n
\n
\n
\n
\n Return a status code indicating the summary of the tests\n executed.\n
\n This argument controls which test cases will be executed. The value\n is a comma separated list of test specifiers. Test cases are arranged\n as leaves on a tree structure, with every test case belonging to a\n test suite. The test runner always creates a master test suite. Named\n test suites are children of the master test suite or another named\n test suite. Any test case that is not the child of a named test suite\n is a child of the unnamed master test suite.\n
\n
\n Test specifiers select test cases or suites by naming the path from\n the unnamed master test suite to the case or suite, similar to a full\n path to a file in a hierarchical directory structure. A test specifier\n is one or more path specifiers, separated by a slash (/).\n A test specifier begins at the master test suite and proceeds down\n the test tree, naming suites or test cases.\n
\n
\n The argument --report_level\n set to detailed can be used to output the names\n of all the test suites and test cases within those test suites.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Path Specifier\n
\n
\n
\n
\n Tests Selected\n
\n
\n
\n\n
\n
\n
\n name\n
\n
\n
\n
\n The test case or suite named name.\n
\n
\n
\n
\n
\n
\n *name\n
\n
\n
\n
\n All test cases or suites whose name ends in name.\n
\n
\n
\n
\n
\n
\n name*\n
\n
\n
\n
\n All test cases or suites whose name begins with name.\n
\n
\n
\n
\n
\n
\n *name*\n
\n
\n
\n
\n All test cases or suites whose name contains name.\n
\n
\n
\n
\n
\n
\n *\n
\n
\n
\n
\n All test cases or suites.\n
\n
\n
\n
\n
\n
\n spec1,spec2,...\n
\n
\n
\n
\n The test cases or suites with the given specifier.\n
\n
\n
\n
\n
\n
\n spec1/spec2\n
\n
\n
\n
\n The test cases or suites matched by spec2\n in the test suite matched by spec1.\n
\n This argument informs the test runner of a boolean value used to create\n or save a test pattern for file-based testing. The test case uses the\n boolean value to determine whether or not it writes the test pattern\n by exercising the system under test or reads the test pattern for comparison\n against the values produced by the system under test. The output_test_stream\n class provides a facility for recording and matching against save patterns.\n
\n This parameter instructs the test runner to print progress through\n the test cases. The test runner has no way of determining the length\n of time each test case will consume; the progress percentage is determined\n by counting test cases.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n Value\n
\n
\n
\n
\n Meaning\n
\n
\n
\n\n
\n
\n
\n no (default)\n [Do not show test execution progress.\n
\n BOOST_TEST_CHECKPOINT(message)\n registers a test case checkpoint and associated message\n with the test runner. A checkpoint includes the source file and line\n number where the macro was invoked. If the test case is aborted unexpectedly,\n the soruce location and message associated with the last registered\n checkpoint is emitted into the log. Checkpoints can be used to identify\n the location of an unexpected failure within a block of test case code.\n The message is applied to an output stream\n with operator<<\n and can include other invocations of operator<<.\n
\n The test_case class represents a single test case. A\n test case must be added to a test suite reachable from the master test\n suite in order for the test runner to run the test case.\n
\n The test_unit class forms the basis of the hierarchical\n tree of test cases. Test applications will usually create instances of\n test_case or test_suite, both of\n which derive from test_unit.\n
\n
\n
\n
namespaceboost{namespaceunit_test{\n\nclassBOOST_TEST_DECLtest_unit{\npublic:\n enum{type=tut_any};\n\n // Constructor\n test_unit(const_stringtu_name,test_unit_typet);\n\n // dependencies management\n voiddepends_on(test_unit*tu);\n boolcheck_dependencies()const;\n\n // Public r/o properties\n typedefBOOST_READONLY_PROPERTY(test_unit_id,(framework_impl))id_t;\n typedefBOOST_READONLY_PROPERTY(test_unit_id,(test_suite))parent_id_t;\n readonly_property<test_unit_type>p_type;// type for this test unit\n readonly_property<const_string>p_type_name;// \"case\"/\"suite\"\n id_tp_id;// unique id for this test unit\n parent_id_tp_parent_id;// parent test suite id\n\n // Public r/w properties\n readwrite_property<std::string>p_name;// name for this test unit\n readwrite_property<unsigned>p_timeout;// timeout for the test unit execution\n readwrite_property<counter_t>p_expected_failures;// number of expected failures in this test unit\n mutablereadwrite_property<bool>p_enabled;// enabled status for this unit\n\n voidincrease_exp_fail(unsignednum);\n\n};\n\n}}\n
\n The unit_test_log_t class encapsulates the unit test\n log. You obtain a reference to the single global unit test log instance\n with the unit_test_log member.\n
\n unit_test_main initializes the test framework, traverses\n the test tree and reports the result as a the return value of the function.\n Unexpected exceptions and system errors (signals, etc.) are caught and\n mapped to appropriate return values by the function.\n
\n Most of the time you will not need to interact with the classes in Boost.Test\n because the macro facilities for assertions, test cases and test suites hide\n all the details of the classes. If you are adapting legacy test code to Boost.Test\n you may need to interact with these classes in order to leverage existing\n test code without significant refactoring of the legacy test code.\n
\n
\n The predicate_result\n class is used to combine a boolean result from a predicate with a custom\n failure message for reporting additional detail in the context of a failed\n assertion. The test_unit,\n test_case,\n test_suite\n and master_test_suite_t\n classes provide the interface to test suites and their test cases for the\n test runner. The test_observer,\n unit_test_log_t\n and unit_test_log_formatter\n classes provide low-level interaction with the test runner log.\n
\n The BOOST_AUTO_TEST_SUITE(name)\n macro defines an automatically registered test suite named name\n and opens a namespace named name.\n
\n
\n A test suite can be nested within another test suite. Each test suite begun\n with BOOST_AUTO_TEST_SUITE must be ended with BOOST_AUTO_TEST_SUITE_END\n The new test suite is registered within its enclosing test suite, or the\n master test suite if there is no enclosing test suite.\n
\n The BOOST_AUTO_TEST_SUITE_END() macro ends the test\n suite most recently defined with BOOST_AUTO_TEST_SUITE\n or BOOST_FIXTURE_TEST_SUITE.\n The corresponding namespace created when the test suite was defined is\n closed by BOOST_AUTO_TEST_SUITE_END.\n
\n The BOOST_FIXTURE_TEST_SUITE(suite,\n fixture) macro begins the\n test suite named suite and uses fixture\n as a test fixture to be used as the base class of all test case classes\n created in the suite with BOOST_AUTO_TEST_CASE.\n
\n The BOOST_TEST_MODULE macro is used to define the name\n of the master test suite. If BOOST_TEST_MODULE is defined,\n it should be defined in exactly one source file. It can be defined to a\n list of preprocessor tokens or a string literal. If a string literal is\n used, surrounding quotation marks (\"), will not\n appear in the name of the master test suite.\n
\n The BOOST_TEST_SUITE(name)\n macro is used to create a new test suite named name.\n The new suite must be added to the master test suite in order for any test\n cases in the suite to be executed.\n
\n A test suite is an ordered collection of test cases and other test suites.\n The test cases in a suite are executed in the order in which they are added\n to the suite. When test cases are automatically registered, they are added\n to the test suite in the order of their definition in the source file.\n
\n Suppose we wish to test that the following function, declared in hello.hpp\n and supplied by a static library hello, inserted the text\n Hello, world!\\n to the given stream:\n
\n We compile test_hello.cpp and link it against the static\n library hello using the build environment for our platform\n to produce an executable. No other source files or libraries are needed.\n When we run the executable, it will execute our test case.\n
\n
\n Suppose that our implementation of hello_world looks like\n this:\n
\n When we run the unit test executable we obtain output similar to the following:[1]\n
\n
Running 1 test case...\nsrc/tutorials/hello_test/1/test/test_hello.cpp(13): fatal error in \"hello_world_inserts_text\": critical check \"Hello, world!\\n\" == dest.str() failed [Hello, world!\n != ]\n\n*** 1 failure detected in test suite \"Master Test Suite\"\n\nEXIT STATUS: 201\n
\n
\n Oops, it looks like we forgot to implement hello_world!.\n Let's fix that by changing hello.cpp to the following:\n
\n We rebuild our library, relink our unit test executable again and re-run\n the test:\n
\n
Running 1 test case...\n\n*** No errors detected\n\nEXIT STATUS: 0\n
\n
\n Now all our tests are passing and we know that hello_world\n does what we expect it to do. We used std::endl to insert\n the newline character and it also flushes the output stream after inserting\n the newline. If we didn't want the output stream to be flushed, we can change\n hello_world to use a character literal:\n
\n Now that we've seen Boost.Test in action, let's take a closer look at what\n we have just done:\n
\n
\n
\n The entire unit test framework was brought into our test application\n with a single include <boost/test/included/unit_test.hpp>.\n We didn't link against any libraries or introduce any run-time dependencies.\n
\n
\n We didn't write an implementation of main, but our\n test executable linked and ran. Why? The preprocessor symbol BOOST_TEST_MAIN\n instructed Boost.Test to supply an implementation of main\n that executes all tests registered with the framework.\n
\n
\n The macro BOOST_AUTO_TEST_CASE\n registered our unit test case with the framework and provides the necessary\n preamble for the implementation of the testing function.\n
\n
\n The argument to BOOST_AUTO_TEST_CASE\n is the name of our test case and is a C++ identifier, not a string.\n
\n
\n The test was structured in three phases: setup, exercise, and verify.\n
\n
\n Our setup phase created an output string stream in order to capture\n the output of hello_world, the system under\n test.\n
\n
\n The exercise phase called the system under test, our function\n hello_world.\n
\n
\n The verify phase checked that the function provided the expected\n output using the assertion macro BOOST_REQUIRE_EQUAL.\n
\n
\n To make the phases of the test obvious, we used blank lines to\n separate them.\n
\n
\n
\n
\n A failing test emits a message that provides information about the location\n of the failed assertion and the detail of the failure.\n
\n
\n The above sequence is a typical example of test-driven development, proceeding\n through stages of \"red\", \"green\" and \"refactor\".\n
\n
\n We wrote a failing test and just enough implementation to compile\n the test (\"red\").\n
\n
\n We then wrote the implementation and ran the test to verify our\n implementation. We made a simple mistake, so we corrected that\n and re-ran the test to verify our implementation by passing the\n test (\"green\").\n
\n
\n Once our implementation was correct, we looked at possible improvements\n we might make to the code; in our case we eliminated the side-effect\n of flushing the output stream (\"refactor\").\n
\n
\n
\n
\n The test code and production code, or system under test, are kept separate.\n The production code was in a library and the test code was in an executable.\n
\n
\n No news is good news! We don't see any noise from test cases when they\n pass and the test executable emits only a summary of all test cases when\n all tests pass.\n
[1] \n The test runner output here is generated from the run-fail\n rule in Boost.Build which includes the output from the executable and appends\n the exit code of the process to the output.\n
\n As we continue to add unit tests for a library, we can get quite a large\n number of tests. If they are true unit tests and each test exercises a single\n class isolated from its collaborators, then most of the tests are not relevant\n to the changes we are making. The test executable accepts a number of command-line\n arguments that allow us to control the behavior of the test framework, including\n which tests to run.\n
\n
\n We can list the available tests in a test executable with --report_level\n set to detailed:\n
\n
> test_hello --report_level=detailed\nRunning 2 test cases...\n\nTest suite \"Master Test Suite\" passed with:\n 2 assertions out of 2 passed\n 2 test cases out of 2 passed\n\n Test case \"hello_world_inserts_text\" passed with:\n 1 assertion out of 1 passed\n\n Test case \"hello_world_stream_with_badbit_throws_runtime_error\" passed with:\n 1 assertion out of 1 passed\n\n
\n
\n
\n
\n
Caution
\n
\n
\n The arguments to the test executable, such as --report_level,\n use an underscore (_) to separate words, not a dash\n (-).\n
\n
\n
\n Suppose we are continuing to make changes to hello_world\n and we want to run only the tests that apply to that function. We can easily\n identify the relevant tests in the output of --report_level\n because we have used a test naming convention of prefixing all test case\n names with the name of the system under test, hello_world.\n
\n
\n Using the --run_test\n argument, we can specify a comma-separated list of test case names to run:\n
\n
> test_hello --run_test=hello_world_inserts_text,hello_world_stream_with_badbit_throws_runtime_error\nRunning 2 test cases...\n\n*** No errors detected\n\nEXIT STATUS: 0\n
\n
\n Wow, that's really a mouthfull! Even with command recall, typing this command\n for the first time will require typing the exact names of all the test cases\n for hello_world. As we add more test cases, we'll have\n to extend the command line argument to account for each new test case.\n
\n
\n We can solve this problem by using test suites, which organize tests into\n a named group:\n
> test_hello --report_level=detailed\nRunning 2 test cases...\n\nTest suite \"Master Test Suite\" passed with:\n 2 assertions out of 2 passed\n 2 test cases out of 2 passed\n\n Test suite \"test_hello\" passed with:\n 2 assertions out of 2 passed\n 2 test cases out of 2 passed\n\n Test case \"hello_world_inserts_text\" passed with:\n 1 assertion out of 1 passed\n\n Test case \"hello_world_stream_with_badbit_throws_runtime_error\" passed with:\n 1 assertion out of 1 passed\n\n
\n
\n The indentation shows that the test cases for hello_world\n are organized under the test suite named test_hello_world.\n
\n
\n
\n
\n
Note
\n
\n
\n We can't name the suite hello_world because that would\n conflict with the name of our system under test, as both are declared in\n the same global namespace.\n
\n
\n
\n Now we can supply the name of the test suite to --run_test\n to run all the test cases in the suite:\n
\n
> test_hello --run_test=test_hello\nRunning 2 test cases...\n\n*** No errors detected\n\nEXIT STATUS: 0\n
\n
\n As we add more test cases to the suite, we don't have to change the command\n we are using to run the tests and we don't need to remember the exact names\n of the test cases.\n
\n
\n Suites arrange test cases into a hierarchy. You can have suites within suites\n to provide larger groupings to test a collection of related classes together.\n Once a test case is part of a suite, we must use the name of the enclosing\n suite with the name of the test case if we wish to run a single test case\n within the suite by name:\n
\n
> test_hello --run_test=test_hello/hello_world_inserts_text\nRunning 1 test case...\n\n*** No errors detected\n
\n
\n The names of the enclosing suites are separated from each other and from\n the test case name with a slash (/). The names supplied\n to --run_test\n also allow for wildcard matching:\n
\n
> test_hello --run_test=hello_world/*inserts_text\nRunning 1 test case...\n\n*** No errors detected\n
\n
\n Just as we can use a fixture with a test case to eliminate repeated setup\n and tear down, we can use a fixture with a test suite. All test cases in\n the test suite will derive from the test suite's fixture. If a test case\n in a test suite with a fixture specifies its own fixture, then the test case\n derives from the fixture specified on the test case and not on the test suite.\n If you want the test case to use both fixtures, then make your test case\n fixture derive from the test suite fixture.\n
\n
\n We can use a test suite fixture for test_hello to take\n care of the duplicated setup between test cases. Since our test cases are\n now within the scope of a suite, we don't need to give them a unique prefix\n anymore. Refactoring the tests to use a suite fixture and discarding the\n prefix gives us the following code:\n
> test_hello.exe --report_level=detailed\nRunning 2 test cases...\n\nTest suite \"Master Test Suite\" passed with:\n 2 assertions out of 2 passed\n 2 test cases out of 2 passed\n\n Test suite \"test_hello\" passed with:\n 2 assertions out of 2 passed\n 2 test cases out of 2 passed\n\n Test case \"inserts_text\" passed with:\n 1 assertion out of 1 passed\n\n Test case \"stream_with_badbit_throws_runtime_error\" passed with:\n 1 assertion out of 1 passed\n\n
\n When we're testing a system, we want to test the failure cases as well as\n the success cases. This means forcing the system under test down an error\n path by orchestrating bad inputs or synthesizing errors from code collaborating\n with the system under test.\n
\n
\n Let's add the requirement that hello_world\n should throw the a std::runtime_error exception if the\n supplied stream has the badbit set on the stream.\n
\n
\n We can add a test case for this:\n
\n
\n
\n
BOOST_AUTO_TEST_CASE(hello_world_stream_with_badbit_throws_runtime_error)\n{\n std::ostringstreamdest;\n dest.clear(std::ios_base::badbit);\n\n hello_world(dest);\n\n BOOST_FAIL(\"std::runtime_error not thrown\");\n}\n
\n
\n
\n
\n
\n
\n
Note
\n
\n
\n The clear\n member function on a stream clears all state bits and sets the\n state to the value of the argument.\n
\n
\n
\n Instead of an assertion macro like BOOST_REQUIRE_EQUAL,\n we're using the BOOST_FAIL\n macro that guarantees test failure. If the call to hello_world\n doesn't throw a runtime_error exception and continues\n to the next line of code, then this test case fails:\n
\n
Running 2 test cases...\nsrc/tutorials/testing_with_exceptions/1/test/test_hello.cpp(24): fatal error in \"hello_world_stream_with_badbit_throws_runtime_error\": std::runtime_error not thrown\n\n*** 1 failure detected in test suite \"Master Test Suite\"\n\nEXIT STATUS: 201\n
\n
\n Now let's enhance the implementation to support this requirement:\n
\n We run our test and get something similar to the following:\n
\n
Running 2 test cases...\nunknown location(0): fatal error in \"hello_world_stream_with_badbit_throws_runtime_error\": std::runtime_error: bad stream\nsrc/tutorials/testing_with_exceptions/2/test/test_hello.cpp(13): last checkpoint\n\n*** 1 failure detected in test suite \"Master Test Suite\"\n\nEXIT STATUS: 201\n
\n
\n Now the test is still failing, so what did we do wrong? The exception from\n our system under test unwound the call stack back into the unit test framework,\n which caught the exception and reported this as a failure. We need to tell\n the test framework that an exception is expected in this situation. We can\n use BOOST_REQUIRE_THROW\n to tell the test framework that an expression is expected to throw a particular\n type of exception. If the exception isn't thrown or an exception of a different\n type is thrown, then the test fails. Our test now looks like this:\n
\n We gave our test case a name that revealed the essence of what it tests\n so that when it fails, we know immediately from the name of the test\n what requirement has been invalidated. Using intention revealing names\n for test cases is just as important as using intention revealing names\n for methods, functions and classes.\n
\n
\n We kept each scenario we wanted to test separate and independent from\n each other. This keeps our tests robust; the state of one test does not\n interfere with any other test.\n
\n
\n Now that we have two test cases, we can see that there is some duplication\n between them: the construction of an output string stream. It isn't much\n right now, just a single line, but duplication between tests is something\n we'll need to watch.\n
\n
\n Every time we modify or add a test, we have to recompile our single test\n file test_hello.cpp, which is including the entire\n unit test framework source. This leads to a lengthy compile every time\n we have to change the tests.\n
\n When we added our second test case in the previous\n tutorial, we ended up with some duplicated setup between the two test\n cases. This is a common occurrence in unit testing. We have some prerequisites\n for the system under test that must be prepared in order to exercise the\n system. In our case, it is a single output string stream that we use for\n capturing the output of our hello_world function.\n
\n
\n Boost.Test provides a facility called a fixture for encapsulating repeated\n setup and tear down code between test cases. In our example, there isn't\n any explicit tear down code because the output string streams are created\n on the stack and destroyed when execution exits the test case. We have a\n little bit of repeated setup code that we can move to a fixture that is used\n by both our test cases. Let's put that repeated code in a fixture:\n
\n A fixture is simply a class or struct that is inherited by the test case.\n We connect the test case to the fixture by using BOOST_FIXTURE_TEST_CASE\n instead of BOOST_AUTO_TEST_CASE.\n The latter simply connects each test case to an empty fixture. After refactoring\n the test cases to use a fixture, we run the tests to make sure the tests\n still pass.\n
\n
\n When using a fixture, the order of construction and destruction is as follows\n when a test case is executed:\n
\n
\n
\n The fixture is constructed.\n
\n
\n The test case class is constructed.\n
\n
\n The test case test method is executed\n
\n
\n The test case class is destroyed.\n
\n
\n The fixture is destroyed.\n
\n
\n
\n This process happens for each test case that is executed, ensuring that each\n test case has a fresh fixture and remains independent of other test cases.\n
\n
\n In most cases, the setup will be a little more involved than just creating\n an instance variable and there will be some work done in the constructor\n of the fixture. We could simply use the default constructor and destructor\n of our fixture in this case. We've written the constructor and destructor\n explicitly to emphasize that this is where setup and tear down occur.\n
\n
\n Now that we've transformed the test cases to use a fixture, it seems we've\n simply traded one piece of repetition, the construction of the output string\n stream, for another: the repeated use of the fixture name and system under\n test in our test cases. We can use a custom test case macro to get rid of\n this duplication:\n
\n Every test case has to have a unique name within the scope of its declaration,\n either the global namespace or a custom namespace, which is why we've been\n prefixing our test case names with the name of the system under test, hello_world.\n Once we accumulate a few tests, the chances for a clash between test names\n increases.\n
\n
\n With our custom test case macro, we reduce the chance for a test case name\n clash by ensuring that every test case name is prefixed by the name of the\n system under test. We ensure that every test case for hello_world\n uses the same fixture and we gain some readability of the test cases by eliminating\n the distracting repetition. If we change the name of the fixture, then we\n need only edit the custom test case macro that supplies the fixture name.\n
\n
\n In the next tutorial, we'll see an alternative way of eliminating this duplication\n of the prefixes of test case names.\n
\n These tutorials will get you started using Boost.Test. They are intended to\n be read in order and proceed from the basics of writing\n your first test to running\n selected tests. Once you've finished with the tutorials, you may want\n to read about test case design\n for some suggestions on testing various situations in C++. The full details\n of the framework are provided in the reference\n section.\n
\n
\n
\n
\n
\n
\n\n
\n\n
\n\n\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/html/test_HTML.manifest",
"content": "index.html\ntest/motivation.html\ntest/how_to_read_this_documentation.html\ntest/tutorials.html\ntest/tutorials/hello_test.html\ntest/tutorials/testing_with_exceptions.html\ntest/tutorials/testing_with_fixtures.html\ntest/tutorials/running_selected_tests.html\ntest/guide.html\ntest/guide/compilation.html\ntest/guide/compilation/minimal_header.html\ntest/guide/compilation/_main_.html\ntest/guide/compilation/header_only.html\ntest/guide/compilation/static_library.html\ntest/guide/compilation/shared_library.html\ntest/guide/test_case_design.html\ntest/guide/acceptance_tests.html\ntest/guide/testing_file_io.html\ntest/guide/mocking_collaborators.html\ntest/guide/testing__main_.html\ntest/guide/testing_protected_or_private_members.html\ntest/guide/manually_registering_test_cases_and_suites.html\ntest/reference.html\ntest/reference/configuration_macros.html\ntest/reference/test_case.html\ntest/reference/test_case/boost_auto_test_case.html\ntest/reference/test_case/boost_auto_test_case_expected_failures.html\ntest/reference/test_case/boost_auto_test_case_template.html\ntest/reference/test_case/boost_fixture_test_case.html\ntest/reference/test_case/boost_global_fixture.html\ntest/reference/test_case/boost_param_test_case.html\ntest/reference/test_case/boost_param_class_test_case.html\ntest/reference/test_case/boost_test_case.html\ntest/reference/test_case/boost_test_case_template.html\ntest/reference/test_case/boost_test_case_template_function.html\ntest/reference/test_suite.html\ntest/reference/test_suite/boost_auto_test_suite.html\ntest/reference/test_suite/boost_auto_test_suite_end.html\ntest/reference/test_suite/boost_fixture_test_suite.html\ntest/reference/test_suite/boost_test_module.html\ntest/reference/test_suite/boost_test_suite.html\ntest/reference/test_classes.html\ntest/reference/test_classes/predicate_result.html\ntest/reference/test_classes/test_unit.html\ntest/reference/test_classes/test_case.html\ntest/reference/test_classes/test_suite.html\ntest/reference/test_classes/master_test_suite_t.html\ntest/reference/test_classes/test_observer.html\ntest/reference/test_classes/unit_test_log_t.html\ntest/reference/test_classes/unit_test_log_formatter.html\ntest/reference/test_classes/init_unit_test_func.html\ntest/reference/test_classes/unit_test_main.html\ntest/reference/assertion.html\ntest/reference/assertion/levels.html\ntest/reference/assertion/_boost____level___bitwise_equal_.html\ntest/reference/assertion/_boost____level___close_.html\ntest/reference/assertion/_boost____level___close_fraction_.html\ntest/reference/assertion/boost_level_equal.html\ntest/reference/assertion/_boost____level___equal_collections_.html\ntest/reference/assertion/boost_level_exception.html\ntest/reference/assertion/boost_fail.html\ntest/reference/assertion/_boost____level___ge_.html\ntest/reference/assertion/_boost____level___gt_.html\ntest/reference/assertion/_boost____level___le_.html\ntest/reference/assertion/_boost____level___lt_.html\ntest/reference/assertion/boost_level_message.html\ntest/reference/assertion/_boost____level___ne_.html\ntest/reference/assertion/boost_level_no_throw.html\ntest/reference/assertion/_boost____level___predicate_.html\ntest/reference/assertion/_boost____level___small_.html\ntest/reference/assertion/boost_level_throw.html\ntest/reference/assertion/boost_test_dont_print_log_value.html\ntest/reference/runner.html\ntest/reference/runner/argument.html\ntest/reference/runner/argument/auto_start_dbg.html\ntest/reference/runner/argument/___build_info_.html\ntest/reference/runner/argument/___catch_system_errors_.html\ntest/reference/runner/argument/___detect_fp_exceptions_.html\ntest/reference/runner/argument/___detect_memory_leaks_.html\ntest/reference/runner/argument/log_format.html\ntest/reference/runner/argument/log_level.html\ntest/reference/runner/argument/log_sink.html\ntest/reference/runner/argument/output_format.html\ntest/reference/runner/argument/___random_.html\ntest/reference/runner/argument/report_format.html\ntest/reference/runner/argument/report_level.html\ntest/reference/runner/argument/report_sink.html\ntest/reference/runner/argument/___result_code_.html\ntest/reference/runner/argument/run_test.html\ntest/reference/runner/argument/___show_progress_.html\ntest/reference/runner/argument/___use_alt_stack_.html\ntest/reference/runner/output.html\ntest/reference/runner/output/log.html\ntest/reference/runner/output/report.html\ntest/reference/runner/output/boost_test_checkpoint.html\ntest/reference/runner/output/boost_test_message.html\ntest/reference/runner/output/_boost_test_passpoint_.html\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nalias src :\n tutorials\n system_under_test\n examples\n ;\n\nbuild-project tutorials ;\nbuild-project system_under_test ;\nbuild-project examples ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/UTF.log.xsd",
"content": "\n\n\t\n\t\t\n\t\t\t\n\t\t\t\tname of the test unit\n\t\t\t\n\t\t\n\t\t\n\t\t\t\n\t\t\t\tSpecified with value \"yes\" only if test unit was skipped during execution\n\t\t\t\n\t\t\n\t\n\t\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\tLine number corresponding to the log entry\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\tfile name corresponding to the log entry\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\n\t\n\t\n\t\t\n\t\t\tException description\n\t\t\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\tLocation of last checkpoint before exception occured\n\t\t\t\t\n\t\t\t\n\t\t\n\t\t\n\t\t\t\n\t\t\t\tobsolete?\n\t\t\t\n\t\t\n\t\n\t\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\tdifferent log entries\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\tLog entry corresponding to the successfully passed assertion\n\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\tLog entry corresponding to the message generated during test execution\n\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\tLog entry corresponding to the warning generated during test execution\n\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\tLog entry corresponding to the non-fatal error occured during test execution\n\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\tLog entry corresponding to the fatal error occured during test execution\n\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\tLog entry corresponding to an exception occured during test execution\n\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\tapproximate time spent on test unit execution\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\n\t\n\t\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\tList of test units composing test suite\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\n\t\n\t\n\t\t\n\t\t\tHolds whole unit test log content\n\t\t\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\tOptional build information for the unit test. \n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\tunique identifier for the platform unit test was compiled on\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\tunique identifier for the compiler unit test was compiled with\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\tunique identifier for the STL implementation used during unit test compilation\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\tversion of the boost used\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\n\t\n\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/UTF.report.xsd",
"content": "\n\n\n\t\n\t\t\n\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\n\t\t\n\t\n\t\n\t\t\n\t\t\t\n\t\t\t\tname of the test unit\n\t\t\t\n\t\t\n\t\t\n\t\t\t\n\t\t\t\tresult status for the test unit: passed, failed, skipped or aborted\n\t\t\t\n\t\t\n\t\t\n\t\t\t\n\t\t\t\tnumber of assertions that passed during execution of the test unit\n\t\t\t\n\t\t\n\t\t\n\t\t\t\n\t\t\t\tnumber of assertion that failed during execution of the test unit\n\t\t\t\n\t\t\n\t\t\n\t\t\t\n\t\t\t\tnumber of assertions that expected to fail in the test unit\n\t\t\t\n\t\t\n\t\n\t\n\t\t\n\t\t\t\n\t\t\n\t\n\t\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\tnumber of test cases that passed in the test suite\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\tnumber of test cases that failed in the test suite\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\tnumber of test cases that were skipped in the test suite\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\tnumber of test cases in the test suite that were aborted during execution by an exception or a fatal error\n\t\t\t\t\n\t\t\t\n\t\t\n\t\n\t\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\n\t\n\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nalias examples :\n compilation//compilation\n assertions\n assertion_failures\n auto_test_case_template\n file_system\n global_fixture\n manual_registration\n param_class_test_case\n param_test_case\n test_case\n test_case_template\n auto_test_case_expected_failures\n ;\n\nalias turtle\n : # no sources\n : # no build requirements\n : # no default build\n : ../../../../../../turtle\n ;\n\nexplicit turtle_mock ;\n\nbuild-project compilation ;\n\nrun assertions.cpp /boost//unit_test_framework ;\nrun auto_test_case_template.cpp /boost//unit_test_framework \n : : : static ;\nrun file_system.cpp ../system_under_test//scanner /boost//filesystem /boost//unit_test_framework\n : : : ../system_under_test/scanner : file_system ;\nrun global_fixture.cpp another_global_fixture.cpp /boost//unit_test_framework\n : : : static ;\nrun manual_registration.cpp ../system_under_test//hello\n : : : ../system_under_test/hello : manual_registration ;\nrun param_class_test_case.cpp ../system_under_test//hello\n : : : ../system_under_test/hello : param_class_test_case ;\nrun param_test_case.cpp ../system_under_test//hello\n : : : ../system_under_test/hello : param_test_case ;\nrun test_case.cpp ../system_under_test//hello\n : : : ../system_under_test/hello : test_case ;\nrun test_case_template.cpp ;\n\nrun-fail auto_test_case_expected_failures.cpp ../system_under_test//hello /boost//unit_test_framework \n : : : ../system_under_test/hello static ;\nrun-fail assertion_failures.cpp /boost//unit_test_framework ;\n\nrun turtle_mock.cpp\n turtle\n ../system_under_test//scanner\n /boost//filesystem\n /boost//unit_test_framework\n : : : ../system_under_test/scanner : turtle_mock ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/another_global_fixture.cpp",
"content": "#include \r\n\r\n#include \r\n\r\nstruct global3\r\n{\r\n global3()\r\n {\r\n std::cout << \"global3 setup\\n\";\r\n }\r\n ~global3()\r\n {\r\n std::cout << \"global3 teardown\\n\";\r\n }\r\n};\r\n\r\nBOOST_GLOBAL_FIXTURE(global3);\r\n\r\nBOOST_AUTO_TEST_CASE(three)\r\n{\r\n std::cout << \"three\\n\";\r\n\r\n BOOST_REQUIRE(true);\r\n}\r\n\r\nstruct global4\r\n{\r\n global4()\r\n {\r\n std::cout << \"global4 setup\\n\";\r\n }\r\n ~global4()\r\n {\r\n std::cout << \"global4 teardown\\n\";\r\n }\r\n};\r\n\r\nBOOST_GLOBAL_FIXTURE(global4);\r\n\r\nBOOST_AUTO_TEST_CASE(four)\r\n{\r\n std::cout << \"four\\n\";\r\n\r\n BOOST_REQUIRE(true);\r\n}\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/assertion_failures.cpp",
"content": "#define BOOST_TEST_MAIN\n#include \n\n#include \n\n//[example_fail\nBOOST_AUTO_TEST_CASE(example_fail)\n{\n BOOST_FAIL(\"This should never happen.\");\n}\n//]\n\n//[example_passpoint\nBOOST_AUTO_TEST_CASE(example_passpoint)\n{\n BOOST_TEST_PASSPOINT();\n\n throw std::runtime_error(\"Oops\");\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/assertions.cpp",
"content": "//[example_test_module\n#define BOOST_TEST_MAIN\n#define BOOST_TEST_MODULE \"Assertions\"\n#include \n//]\n\n#include \n#include \n#include \n#include \n#include \n#include \n\n//[example_bitwise_equal\nenum bit_flags\n{\n source_file = 1u,\n header_file = 2u,\n build_file = 4u\n};\n\nBOOST_AUTO_TEST_CASE(example_bitwise_equal)\n{\n BOOST_REQUIRE_BITWISE_EQUAL(\n source_file | build_file,\n build_file | source_file);\n}\n//]\n\n//[example_close\nBOOST_AUTO_TEST_CASE(example_close)\n{\n BOOST_REQUIRE_CLOSE(100.f, 100.9f, 1.f);\n BOOST_REQUIRE_CLOSE(100.f, 99.1f, 1.f);\n}\n//]\n\n//[example_close_fraction\nBOOST_AUTO_TEST_CASE(example_close_fraction)\n{\n BOOST_REQUIRE_CLOSE_FRACTION(100.f, 100.9f, 1.f);\n BOOST_REQUIRE_CLOSE_FRACTION(100.f, 99.1f, 1.f);\n}\n//]\n\n//[example_equal\nBOOST_AUTO_TEST_CASE(example_equal)\n{\n // integral types\n unsigned const u = 1u;\n int const i = -1;\n char const A = 'A';\n // standard library types providing operator== and operator<<\n std::string const s = \"scooby\";\n\n BOOST_REQUIRE_EQUAL(1u, u);\n BOOST_REQUIRE_EQUAL(-1, i);\n BOOST_REQUIRE_EQUAL('A', A);\n BOOST_REQUIRE_EQUAL(\"scooby\", s);\n}\n//]\n\n//[example_equal_custom_compare\n// custom data structure\nstruct symbol\n{\n char const* const name;\n int value;\n};\n\n// custom comparison operator\nstatic bool operator==(symbol const& lhs, symbol const& rhs)\n{\n return lhs.value == rhs.value\n && std::string(lhs.name) == std::string(rhs.name);\n}\n\n// custom stream insertion operator\nstatic std::ostream& operator<<(std::ostream& stream, symbol const& value)\n{\n return stream << value.name << \": \" << value.value;\n}\n\nBOOST_AUTO_TEST_CASE(example_equal_custom_compare)\n{\n symbol const s1 = { \"var\" , 1 };\n symbol const s2 = { \"var\", 1 };\n // If the compiler doesn't collapse multiple constants, then:\n // s1.name != s2.name;\n\n BOOST_REQUIRE_EQUAL(s1, s2);\n}\n//]\n\n//[example_equal_collections\nstatic std::list generate_list()\n{\n std::list l;\n l.push_front(3);\n l.push_front(2);\n l.push_front(1);\n\n return l;\n}\n\nBOOST_AUTO_TEST_CASE(example_equal_collections)\n{\n std::vector expected;\n expected.push_back(1);\n expected.push_back(2);\n expected.push_back(3);\n\n std::list actual = generate_list();\n\n BOOST_REQUIRE_EQUAL_COLLECTIONS(\n expected.begin(), expected.end(),\n actual.begin(), actual.end());\n}\n\nBOOST_AUTO_TEST_CASE(example_equal_collections_pod)\n{\n int const expected[] = { 1, 2, 3 };\n\n std::list actual = generate_list();\n\n BOOST_REQUIRE_EQUAL_COLLECTIONS(\n &expected[0], &expected[sizeof(expected)/sizeof(expected[0])],\n actual.begin(), actual.end());\n}\n//]\n\n//[example_exception\nclass error_number_exception\n{\npublic:\n error_number_exception(int num)\n : num_(num)\n { }\n\n int error_number() const { return num_; }\n\nprivate:\n int num_;\n};\n\nstatic bool has_error_number_1(error_number_exception const& ex)\n{\n return ex.error_number() == 1;\n}\n\nBOOST_AUTO_TEST_CASE(example_exception)\n{\n BOOST_REQUIRE_EXCEPTION(throw error_number_exception(1),\n error_number_exception, has_error_number_1);\n}\n//]\n\n//[example_ge\nBOOST_AUTO_TEST_CASE(example_ge)\n{\n // integral types\n unsigned const u = 1u;\n int const i = -10;\n char const A = 'A';\n // standard library types providing operator>= and operator<<\n std::string const s = \"scooby\";\n\n BOOST_REQUIRE_GE(2u, u);\n BOOST_REQUIRE_GE(1u, u);\n BOOST_REQUIRE_GE(-9, i);\n BOOST_REQUIRE_GE(-10, i);\n BOOST_REQUIRE_GE('B', A);\n BOOST_REQUIRE_GE('A', A);\n BOOST_REQUIRE_GE(\"scoobz\", s);\n BOOST_REQUIRE_GE(\"scooby\", s);\n}\n//]\n\n//[example_gt\nBOOST_AUTO_TEST_CASE(example_gt)\n{\n // integral types\n unsigned const u = 1u;\n int const i = -10;\n char const A = 'A';\n // standard library types providing operator> and operator==\n std::string const s = \"scooby\";\n\n BOOST_REQUIRE_GT(2u, u);\n BOOST_REQUIRE_GT(-9, i);\n BOOST_REQUIRE_GT('B', A);\n BOOST_REQUIRE_GT(\"scoobz\", s);\n}\n//]\n\n//[example_le\nBOOST_AUTO_TEST_CASE(example_le)\n{\n // integral types\n unsigned const u = 10u;\n int const i = -10;\n char const M = 'M';\n // standard library types providing operator>= and operator<<\n std::string const s = \"scooby\";\n\n BOOST_REQUIRE_LE(9u, u);\n BOOST_REQUIRE_LE(10u, u);\n BOOST_REQUIRE_LE(-11, i);\n BOOST_REQUIRE_LE(-10, i);\n BOOST_REQUIRE_LE('L', M);\n BOOST_REQUIRE_LE('M', M);\n BOOST_REQUIRE_LE(\"scoobx\", s);\n BOOST_REQUIRE_LE(\"scooby\", s);\n}\n//]\n\n//[example_lt\nBOOST_AUTO_TEST_CASE(example_lt)\n{\n // integral types\n unsigned const u = 10u;\n int const i = -10;\n char const M = 'M';\n // standard library types providing operator>= and operator<<\n std::string const s = \"scooby\";\n\n BOOST_REQUIRE_LT(9u, u);\n BOOST_REQUIRE_LT(-11, i);\n BOOST_REQUIRE_LT('L', M);\n BOOST_REQUIRE_LT(\"scoobx\", s);\n}\n//]\n\n//[example_message\nstatic int g_i;\n\n// simple predicate\nstatic bool global_int_is_positive()\n{\n return g_i > 0;\n}\n\n// predicate that builds up detail message\nstatic boost::test_tools::predicate_result global_int_equal(int expected)\n{\n if (g_i == expected)\n {\n return true;\n }\n\n boost::test_tools::predicate_result failed = false;\n failed.message() << \"g_i != \" << expected << \"; actual: \" << g_i;\n return failed;\n}\n\nBOOST_AUTO_TEST_CASE(example_message)\n{\n g_i = 1;\n\n BOOST_REQUIRE_MESSAGE(global_int_is_positive(),\n \"g_i is not positive; actual: \" << g_i);\n BOOST_REQUIRE_MESSAGE(global_int_equal(1), \"g_i equals 1\");\n}\n//]\n\n//[example_ne\nBOOST_AUTO_TEST_CASE(example_ne)\n{\n // integral types\n unsigned const u = 1u;\n int const i = -1;\n char const A = 'A';\n // standard library types providing operator!= and operator<<\n std::string const s = \"scooby\";\n\n BOOST_REQUIRE_NE(2u, u);\n BOOST_REQUIRE_NE(-2, i);\n BOOST_REQUIRE_NE('B', A);\n BOOST_REQUIRE_NE(\"scoobz\", s);\n}\n//]\n\n//[example_no_throw\nBOOST_AUTO_TEST_CASE(example_no_throw)\n{\n BOOST_REQUIRE_NO_THROW(1 + 1);\n}\n//]\n\n//[example_predicate\nstatic bool custom_string_compare(char const* const expected, char const* const actual)\n{\n return std::strcmp(expected, actual) == 0;\n}\n\nBOOST_AUTO_TEST_CASE(example_predicate)\n{\n char const* const s = \"scooby\";\n\n BOOST_REQUIRE_PREDICATE(custom_string_compare, (\"scooby\")(s));\n}\n//]\n\n//[example_small\nBOOST_AUTO_TEST_CASE(example_small)\n{\n float const f = 0.1f;\n\n BOOST_REQUIRE_SMALL(f, 0.25f);\n}\n//]\n\n//[example_throw\nstatic void always_throws()\n{\n throw std::runtime_error(\"whoops\");\n}\n\nBOOST_AUTO_TEST_CASE(example_throw)\n{\n BOOST_REQUIRE_THROW(always_throws(), std::runtime_error);\n}\n//]\n\n//[example_test_dont_print_log_value\nstruct custom\n{\n int value;\n};\n\nBOOST_TEST_DONT_PRINT_LOG_VALUE(custom);\n\nstatic bool operator==(custom const& expected, custom const& actual)\n{\n return expected.value == actual.value;\n}\n\nBOOST_AUTO_TEST_CASE(example_test_dont_print_log_value)\n{\n custom const v1 = { 1 };\n custom const v2 = { 1 };\n BOOST_REQUIRE_EQUAL(v1, v2);\n}\n//]\n\n//[example_checkpoint\nBOOST_AUTO_TEST_CASE(example_checkpoint)\n{\n int const i = 0;\n BOOST_TEST_CHECKPOINT(\"i = \" << i);\n\n BOOST_REQUIRE(i == 0);\n}\n//]\n\n//[example_test_message\nBOOST_AUTO_TEST_CASE(example_test_message)\n{\n int const i = 0;\n BOOST_TEST_MESSAGE(\"i = \" << i);\n\n BOOST_REQUIRE(i == 0);\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/auto_test_case_expected_failures.cpp",
"content": "#define BOOST_TEST_MAIN\r\n#include \r\n#include \"hello.hpp\"\r\n#include \r\n\r\nBOOST_AUTO_TEST_CASE_EXPECTED_FAILURES(inserts_text_check_expected, 2)\r\nBOOST_AUTO_TEST_CASE(inserts_text_check_expected)\r\n{\r\n std::ostringstream dest;\r\n\r\n hello_world(dest);\r\n\r\n BOOST_CHECK_EQUAL(\"scooby-doo\", dest.str());\r\n BOOST_CHECK_EQUAL(\"shaggy\", dest.str());\r\n}\r\n\r\nBOOST_AUTO_TEST_CASE_EXPECTED_FAILURES(inserts_text_check_exceeded, 2)\r\nBOOST_AUTO_TEST_CASE(inserts_text_check_exceeded)\r\n{\r\n std::ostringstream dest;\r\n\r\n hello_world(dest);\r\n\r\n BOOST_CHECK_EQUAL(\"scooby-doo\", dest.str());\r\n BOOST_CHECK_EQUAL(\"shaggy\", dest.str());\r\n BOOST_CHECK_EQUAL(\"SCOOBY\", dest.str());\r\n}\r\n\r\n//[expected_failures\r\nBOOST_AUTO_TEST_CASE_EXPECTED_FAILURES(inserts_text_require_expected, 1)\r\nBOOST_AUTO_TEST_CASE(inserts_text_require_expected)\r\n{\r\n std::ostringstream dest;\r\n\r\n hello_world(dest);\r\n\r\n BOOST_REQUIRE_EQUAL(\"scooby-doo\", dest.str());\r\n}\r\n//]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/auto_test_case_template.cpp",
"content": "#define BOOST_TEST_MODULE auto_test_case_template\r\n#define BOOST_TEST_MAIN\r\n#include \r\n\r\n//[auto_test_case_template\r\n#include \r\n#include \r\n\r\ntypedef boost::mpl::list<\r\n unsigned char, unsigned short,\r\n unsigned int,\r\n unsigned long, unsigned long long> unsigned_types;\r\n\r\nBOOST_AUTO_TEST_CASE_TEMPLATE(not_is_signed_for_unsigned_types, T, unsigned_types)\r\n{\r\n BOOST_REQUIRE(!std::numeric_limits::is_signed);\r\n}\r\n//]\r\n\r\ntypedef boost::mpl::list<\r\n char, short,\r\n int,\r\n long, long long> signed_types;\r\nBOOST_AUTO_TEST_CASE_TEMPLATE(is_signed_for_signed_types, T, signed_types)\r\n{\r\n BOOST_REQUIRE(std::numeric_limits::is_signed);\r\n}\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/compilation/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nalias compilation :\n dynamic\n minimal\n static\n ;\n\nexplicit dynamic_main ;\nexplicit static_main ;\n\nrun dynamic/main.cpp dynamic/test_hello.cpp\n ../../system_under_test//hello /boost//unit_test_framework\n : : : ../../system_under_test/hello shared\n : dynamic ;\n\n# The unit test framework needs to be compiled with BOOST_TEST_NO_MAIN\n# for this example to compile.\nrun dynamic_main/main.cpp dynamic_main/test_hello.cpp\n ../../system_under_test//hello /boost//unit_test_framework\n : : : ../../system_under_test/hello shared\n : dynamic_main ;\n\nrun minimal/test_hello.cpp\n ../../system_under_test//hello /boost//unit_test_framework\n : : : ../../system_under_test/hello\n : minimal ;\n\nrun static/main.cpp static/test_hello.cpp\n ../../system_under_test//hello /boost//unit_test_framework \n : : : ../../system_under_test/hello static\n : static ;\n\n# The unit test framework needs to be compiled with BOOST_TEST_NO_MAIN\n# for this example to compile.\nrun static_main/main.cpp static_main/test_hello.cpp\n ../../system_under_test//hello /boost//unit_test_framework\n : : : ../../system_under_test/hello static\n : static_main ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/compilation/dynamic/main.cpp",
"content": "#define BOOST_TEST_DYN_LINK\n#define BOOST_TEST_MAIN\n#include \n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/compilation/dynamic/test_hello.cpp",
"content": "#define BOOST_TEST_DYN_LINK\n#include \n#include \"hello.hpp\"\n#include \n#include \n\nstruct hello_world_fixture\n{\n std::ostringstream dest;\n};\n\nBOOST_FIXTURE_TEST_SUITE(test_hello_world, hello_world_fixture);\n\nBOOST_AUTO_TEST_CASE(inserts_text)\n{\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n\nBOOST_AUTO_TEST_CASE(stream_with_badbit_throws_runtime_error)\n{\n dest.clear(std::ios_base::badbit);\n\n BOOST_REQUIRE_THROW(hello_world(dest), std::runtime_error);\n}\n\nBOOST_AUTO_TEST_SUITE_END();\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/compilation/dynamic_main/main.cpp",
"content": "#define BOOST_TEST_DYN_LINK\n#define BOOST_TEST_NO_MAIN\n#include \n\nbool init_function()\n{\n // create test cases and suites and return a boolean indicating\n // success (true) or failure (false).\n return true;\n}\n\nint main(int argc, char* argv[])\n{\n return ::boost::unit_test::unit_test_main(&init_function, argc, argv);\n}\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/compilation/dynamic_main/test_hello.cpp",
"content": "#define BOOST_TEST_DYN_LINK\n#define BOOST_TEST_NO_MAIN\n#include \n#include \"hello.hpp\"\n#include \n#include \n\nstruct hello_world_fixture\n{\n std::ostringstream dest;\n};\n\nBOOST_FIXTURE_TEST_SUITE(test_hello_world, hello_world_fixture);\n\nBOOST_AUTO_TEST_CASE(inserts_text)\n{\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n\nBOOST_AUTO_TEST_CASE(stream_with_badbit_throws_runtime_error)\n{\n dest.clear(std::ios_base::badbit);\n\n BOOST_REQUIRE_THROW(hello_world(dest), std::runtime_error);\n}\n\nBOOST_AUTO_TEST_SUITE_END();\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/compilation/minimal/test_hello.cpp",
"content": "#include \n#include \"hello.hpp\"\n#include \n#include \n\nstatic void inserts_text()\n{\n std::ostringstream dest;\n\n hello_world(dest);\n\n BOOST_REQUIRE(\"Hello, world!\\n\" == dest.str());\n}\n\nstatic void stream_with_badbit_throws_runtime_error()\n{\n std::ostringstream dest;\n dest.clear(std::ios_base::badbit);\n\n try\n {\n hello_world(dest);\n }\n\n catch (std::runtime_error const&)\n {\n return;\n }\n catch (...)\n {\n BOOST_FAIL(\"Unknown exception thrown.\");\n return;\n }\n BOOST_FAIL(\"No exception thrown.\");\n}\n\nint test_main(int /*argc*/, char* /*argv*/[])\n{\n inserts_text();\n stream_with_badbit_throws_runtime_error();\n return 0;\n}\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/compilation/static/main.cpp",
"content": "#define BOOST_TEST_MAIN\n#include \n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/compilation/static/test_hello.cpp",
"content": "#include \n#include \"hello.hpp\"\n#include \n#include \n\nstruct hello_world_fixture\n{\n std::ostringstream dest;\n};\n\nBOOST_FIXTURE_TEST_SUITE(test_hello_world, hello_world_fixture);\n\nBOOST_AUTO_TEST_CASE(inserts_text)\n{\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n\nBOOST_AUTO_TEST_CASE(stream_with_badbit_throws_runtime_error)\n{\n dest.clear(std::ios_base::badbit);\n\n BOOST_REQUIRE_THROW(hello_world(dest), std::runtime_error);\n}\n\nBOOST_AUTO_TEST_SUITE_END();\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/compilation/static_main/main.cpp",
"content": "#define BOOST_TEST_NO_MAIN\n#include \n\nboost::unit_test::test_suite *init_function(int argc, char *argv[])\n{\n // create test cases and suites and return a pointer to any enclosing\n // suite, or 0.\n return 0;\n}\n\nint main(int argc, char *argv[])\n{\n return boost::unit_test::unit_test_main(init_function, argc, argv);\n}\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/compilation/static_main/test_hello.cpp",
"content": "#define BOOST_TEST_NO_MAIN\n#include \n#include \"hello.hpp\"\n#include \n#include \n\nstruct hello_world_fixture\n{\n std::ostringstream dest;\n};\n\nBOOST_FIXTURE_TEST_SUITE(test_hello_world, hello_world_fixture);\n\nBOOST_AUTO_TEST_CASE(inserts_text)\n{\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n\nBOOST_AUTO_TEST_CASE(stream_with_badbit_throws_runtime_error)\n{\n dest.clear(std::ios_base::badbit);\n\n BOOST_REQUIRE_THROW(hello_world(dest), std::runtime_error);\n}\n\nBOOST_AUTO_TEST_SUITE_END();\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/file_system.cpp",
"content": "#define BOOST_TEST_MAIN\r\n#include \r\n#include \"directory_scanner.hpp\"\r\n#include \"scanner.hpp\"\r\n\r\n//[fake_directory_scanner\r\nclass fake_directory_scanner : public directory_scanner\r\n{\r\npublic:\r\n fake_directory_scanner()\r\n : begin_called(false),\r\n has_next_called(false),\r\n next_called(false),\r\n next_call_count(0U)\r\n {}\r\n\r\n virtual ~fake_directory_scanner() {}\r\n\r\n virtual void begin(std::string const &directory)\r\n {\r\n begin_called = true;\r\n begin_last_directory = directory;\r\n }\r\n bool begin_called;\r\n std::string begin_last_directory;\r\n\r\n virtual bool has_next() const\r\n {\r\n has_next_called = true;\r\n return next_call_count <= next_fake_results.size();\r\n }\r\n mutable bool has_next_called;\r\n bool has_next_fake_result;\r\n\r\n virtual std::string next() const\r\n {\r\n next_called = true;\r\n ++next_call_count;\r\n return has_next() ? next_fake_results[next_call_count - 1U] : \"\";\r\n }\r\n mutable bool next_called;\r\n mutable std::size_t next_call_count;\r\n std::vector next_fake_results;\r\n};\r\n//]\r\n\r\n//[test_scanner\r\nstatic std::string const ARBITRARY_DIRECTORY_NAME(\"foo\");\r\nstatic std::string const ARBITRARY_NON_TEXT_FILE_NAME(\"foo.foo\");\r\nstatic std::string const ARBITRARY_TEXT_FILE_NAME(\"foo.txt\");\r\nstatic std::string const ARBITRARY_OTHER_TEXT_FILE_NAME(\"bar.txt\");\r\n\r\nstruct text_files_fixture\r\n{\r\n void expect_enumerate_non_text_file()\r\n {\r\n scanner.next_fake_results.push_back(ARBITRARY_NON_TEXT_FILE_NAME);\r\n }\r\n\r\n void expect_enumerate_text_file(std::string const& file_name = ARBITRARY_TEXT_FILE_NAME)\r\n {\r\n scanner.next_fake_results.push_back(file_name);\r\n expected.push_back(file_name);\r\n }\r\n\r\n fake_directory_scanner scanner;\r\n std::vector empty;\r\n std::vector expected;\r\n};\r\n\r\nBOOST_FIXTURE_TEST_SUITE(test_text_files, text_files_fixture);\r\n\r\nBOOST_AUTO_TEST_CASE(returns_empty_for_empty_directory)\r\n{\r\n std::vector files = text_files(ARBITRARY_DIRECTORY_NAME, scanner);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(empty.begin(), empty.end(), files.begin(), files.end());\r\n}\r\n\r\nBOOST_AUTO_TEST_CASE(returns_empty_for_no_text_files)\r\n{\r\n expect_enumerate_non_text_file();\r\n\r\n std::vector files = text_files(ARBITRARY_DIRECTORY_NAME, scanner);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(empty.begin(), empty.end(), files.begin(), files.end());\r\n}\r\n\r\nBOOST_AUTO_TEST_CASE(returns_file_for_text_file)\r\n{\r\n expect_enumerate_text_file();\r\n\r\n std::vector files = text_files(ARBITRARY_DIRECTORY_NAME, scanner);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(expected.begin(), expected.end(), files.begin(), files.end());\r\n}\r\n\r\nBOOST_AUTO_TEST_CASE(returns_only_text_file_for_mixed_files)\r\n{\r\n expect_enumerate_text_file();\r\n expect_enumerate_non_text_file();\r\n\r\n std::vector files = text_files(ARBITRARY_DIRECTORY_NAME, scanner);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(expected.begin(), expected.end(), files.begin(), files.end());\r\n}\r\n\r\nBOOST_AUTO_TEST_CASE(returns_all_text_files)\r\n{\r\n expect_enumerate_text_file();\r\n expect_enumerate_non_text_file();\r\n expect_enumerate_text_file(ARBITRARY_OTHER_TEXT_FILE_NAME);\r\n\r\n std::vector files = text_files(ARBITRARY_DIRECTORY_NAME, scanner);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(expected.begin(), expected.end(), files.begin(), files.end());\r\n}\r\n\r\nBOOST_AUTO_TEST_SUITE_END();\r\n//]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/global_fixture.cpp",
"content": "#define BOOST_TEST_MAIN\r\n#include \r\n\r\n#include \r\n\r\n//[global_fixture\r\nstruct global_fixture\r\n{\r\n global_fixture()\r\n {\r\n std::cout << \"global setup\\n\";\r\n }\r\n ~global_fixture()\r\n {\r\n std::cout << \"global teardown\\n\";\r\n }\r\n};\r\n\r\nBOOST_GLOBAL_FIXTURE(global_fixture);\r\n//]\r\n\r\nstruct suite_fixture\r\n{\r\n suite_fixture()\r\n {\r\n std::cout << \"suite setup\\n\";\r\n }\r\n ~suite_fixture()\r\n {\r\n std::cout << \"suite teardown\\n\";\r\n }\r\n};\r\n\r\nBOOST_FIXTURE_TEST_SUITE(suite, suite_fixture);\r\n\r\nBOOST_AUTO_TEST_CASE(one)\r\n{\r\n std::cout << \"one\\n\";\r\n\r\n BOOST_REQUIRE(true);\r\n}\r\n\r\nstruct global2\r\n{\r\n global2()\r\n {\r\n std::cout << \"global2 setup\\n\";\r\n }\r\n ~global2()\r\n {\r\n std::cout << \"global2 teardown\\n\";\r\n }\r\n};\r\n\r\nBOOST_GLOBAL_FIXTURE(global2);\r\n\r\nBOOST_AUTO_TEST_CASE(two)\r\n{\r\n std::cout << \"two\\n\";\r\n\r\n BOOST_REQUIRE(true);\r\n}\r\n\r\nBOOST_AUTO_TEST_SUITE_END();\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/manual_registration.cpp",
"content": "#define BOOST_TEST_NO_MAIN\n#include \n#include \"hello.hpp\"\n\nusing namespace boost::unit_test;\n\n//[register_function\nstatic void inserts_text()\n{\n std::ostringstream dest;\n\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n\nstatic void register_function(test_suite& suite)\n{\n suite.add(BOOST_TEST_CASE(inserts_text));\n}\n//]\n\n//[hello_fixture\nclass hello_fixture\n{\npublic:\n void stream_with_badbit_throws_runtime_error()\n {\n dest.clear(std::ios_base::badbit);\n\n BOOST_REQUIRE_THROW(hello_world(dest), std::runtime_error);\n }\n\n std::ostringstream dest;\n};\n//]\n\n//[register_method_static_instance\nstatic hello_fixture hf;\n\nstatic void register_method_static_instance(test_suite& suite)\n{\n suite.add(BOOST_TEST_CASE(\n boost::bind(&hello_fixture::stream_with_badbit_throws_runtime_error,\n &hf)));\n}\n//]\n\n//[register_method_function_instance\nstatic void stream_with_badbit_throws_runtime_error()\n{\n hello_fixture().stream_with_badbit_throws_runtime_error();\n};\n\nstatic void register_method_function_instance(test_suite& suite)\n{\n suite.add(BOOST_TEST_CASE(stream_with_badbit_throws_runtime_error));\n}\n//]\n\n//[register_test_suite\nstatic test_suite*\ninit_unit_test_suite(int argc, char* argv[])\n{\n test_suite* hello_suite = BOOST_TEST_SUITE(\"hello\");\n register_function(*hello_suite);\n register_method_static_instance(*hello_suite);\n register_method_function_instance(*hello_suite);\n framework::master_test_suite().add(hello_suite);\n return 0;\n}\n//]\n\nint main(int argc, char* argv[])\n{\n return unit_test_main(init_unit_test_suite, argc, argv);\n}\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/param_class_test_case.cpp",
"content": "#define BOOST_TEST_NO_MAIN\n#include \n#include \n#include \"hello.hpp\"\n#include \n\n//[param_class_test_case\n#include \n#include \n\nusing namespace boost::unit_test;\n\nclass hello_world_tester\n{\npublic:\n hello_world_tester()\n {\n eq_items.push_back(\"Hello, world!\\n\");\n eq_items.push_back(\"Hello, world!\\n\");\n ne_items.push_back(\"shaggy\");\n ne_items.push_back(\"scooby\");\n }\n\n void inserts_text(std::string const& text)\n {\n std::ostringstream dest;\n\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(text, dest.str());\n };\n\n void does_not_insert_text(std::string const& text)\n {\n std::ostringstream dest;\n\n hello_world(dest);\n\n BOOST_REQUIRE_NE(text, dest.str());\n }\n\n std::vector eq_items;\n std::vector ne_items;\n};\n\nboost::shared_ptr tester(boost::make_shared());\n\nstatic test_suite*\ninit(int argc, char* argv[])\n{\n test_suite& suite = framework::master_test_suite();\n suite.add(BOOST_PARAM_CLASS_TEST_CASE(\n &hello_world_tester::inserts_text, tester,\n tester->eq_items.begin(), tester->eq_items.end()));\n suite.add(BOOST_PARAM_CLASS_TEST_CASE(\n &hello_world_tester::does_not_insert_text, tester,\n tester->ne_items.begin(), tester->ne_items.end()));\n return 0;\n}\n\nint main(int argc, char* argv[])\n{\n return unit_test_main(init, argc, argv);\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/param_test_case.cpp",
"content": "#define BOOST_TEST_NO_MAIN\n#include \n#include \n#include \"hello.hpp\"\n#include \n\n//[param_test_case\nusing namespace boost::unit_test;\n\nstatic void does_not_insert_text(std::string const& text)\n{\n std::ostringstream dest;\n\n hello_world(dest);\n\n BOOST_REQUIRE_NE(text, dest.str());\n}\n\nstatic std::vector text;\n\nstatic test_suite*\ninit(int argc, char* argv[])\n{\n text.push_back(\"scooby\");\n text.push_back(\"shaggy\");\n text.push_back(\"foo\");\n text.push_back(\"arg\");\n framework::master_test_suite()\n .add(BOOST_PARAM_TEST_CASE(does_not_insert_text, text.begin(), text.end()));\n return 0;\n}\n\nint main(int argc, char* argv[])\n{\n return unit_test_main(init, argc, argv);\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/test_case.cpp",
"content": "//[test_case\n#define BOOST_TEST_NO_MAIN\n#include \n#include \"hello.hpp\"\n#include \n\nusing namespace boost::unit_test;\n\nstatic void inserts_text()\n{\n std::ostringstream dest;\n\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n\nstatic test_suite*\ninit(int argc, char* argv[])\n{\n framework::master_test_suite().add(BOOST_TEST_CASE(inserts_text));\n return 0;\n}\n\nint main(int argc, char* argv[])\n{\n return unit_test_main(init, argc, argv);\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/test_case_template.cpp",
"content": "#define BOOST_TEST_NO_MAIN\n#include \n#include \n\nusing namespace boost::unit_test;\n\ntypedef boost::mpl::list<\n unsigned char, unsigned short,\n unsigned int,\n unsigned long, unsigned long long> unsigned_types;\nBOOST_TEST_CASE_TEMPLATE_FUNCTION(not_is_signed_for_unsigned_types, T)\n{\n BOOST_REQUIRE(!std::numeric_limits::is_signed);\n}\n\n//[test_case_template_function\ntypedef boost::mpl::list<\n char, short,\n int,\n long, long long> signed_types;\n\nBOOST_TEST_CASE_TEMPLATE_FUNCTION(is_signed_for_signed_types, T)\n{\n BOOST_REQUIRE(std::numeric_limits::is_signed);\n}\n//]\n\n//[test_case_template\nstatic test_suite*\ninit(int argc, char* argv[])\n{\n test_suite& suite(framework::master_test_suite());\n suite.add(BOOST_TEST_CASE_TEMPLATE(not_is_signed_for_unsigned_types, unsigned_types));\n suite.add(BOOST_TEST_CASE_TEMPLATE(is_signed_for_signed_types, signed_types));\n return 0;\n}\n\nint main(int argc, char* argv[])\n{\n return unit_test_main(init, argc, argv);\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/examples/turtle_mock.cpp",
"content": "#define BOOST_TEST_MAIN\r\n#include \r\n#include \"scanner.hpp\"\r\n\r\n//[mock_directory_scanner\r\n#include \"directory_scanner.hpp\"\r\n#include \r\n\r\nMOCK_BASE_CLASS(mock_directory_scanner, directory_scanner)\r\n{\r\n MOCK_METHOD(begin, 1);\r\n MOCK_METHOD(has_next, 0);\r\n MOCK_METHOD(next, 0);\r\n};\r\n//]\r\n\r\n//[test_scanner_with_mocks\r\nstatic std::string const ARBITRARY_DIRECTORY_NAME(\"foo\");\r\nstatic std::string const ARBITRARY_NON_TEXT_FILE_NAME(\"foo.foo\");\r\nstatic std::string const ARBITRARY_TEXT_FILE_NAME(\"foo.txt\");\r\nstatic std::string const ARBITRARY_OTHER_TEXT_FILE_NAME(\"bar.txt\");\r\n\r\nstruct text_files_fixture\r\n{\r\n text_files_fixture()\r\n {\r\n MOCK_EXPECT(scanner.begin).once().with(ARBITRARY_DIRECTORY_NAME);\r\n }\r\n\r\n void expect_enumerate_non_text_file()\r\n {\r\n MOCK_EXPECT(scanner.has_next).once().returns(true);\r\n MOCK_EXPECT(scanner.next).once().returns(ARBITRARY_NON_TEXT_FILE_NAME);\r\n }\r\n\r\n void expect_enumerate_text_file(std::string const& file_name = ARBITRARY_TEXT_FILE_NAME)\r\n {\r\n MOCK_EXPECT(scanner.has_next).once().returns(true);\r\n MOCK_EXPECT(scanner.next).once().returns(file_name);\r\n expected.push_back(file_name);\r\n }\r\n\r\n void expect_enumerate_end()\r\n {\r\n MOCK_EXPECT(scanner.has_next).once().returns(false);\r\n }\r\n\r\n mock_directory_scanner scanner;\r\n std::vector empty;\r\n std::vector expected;\r\n};\r\n\r\nBOOST_FIXTURE_TEST_SUITE(test_text_files, text_files_fixture);\r\n\r\nBOOST_AUTO_TEST_CASE(returns_empty_for_empty_directory)\r\n{\r\n expect_enumerate_end();\r\n\r\n std::vector files = text_files(ARBITRARY_DIRECTORY_NAME, scanner);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(empty.begin(), empty.end(), files.begin(), files.end());\r\n}\r\n\r\nBOOST_AUTO_TEST_CASE(returns_empty_for_no_text_files)\r\n{\r\n expect_enumerate_non_text_file();\r\n expect_enumerate_end();\r\n\r\n std::vector files = text_files(ARBITRARY_DIRECTORY_NAME, scanner);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(empty.begin(), empty.end(), files.begin(), files.end());\r\n}\r\n\r\nBOOST_AUTO_TEST_CASE(returns_file_for_text_file)\r\n{\r\n expect_enumerate_text_file();\r\n expect_enumerate_end();\r\n\r\n std::vector files = text_files(ARBITRARY_DIRECTORY_NAME, scanner);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(expected.begin(), expected.end(), files.begin(), files.end());\r\n}\r\n\r\nBOOST_AUTO_TEST_CASE(returns_only_text_file_for_mixed_files)\r\n{\r\n expect_enumerate_text_file();\r\n expect_enumerate_non_text_file();\r\n expect_enumerate_end();\r\n\r\n std::vector files = text_files(ARBITRARY_DIRECTORY_NAME, scanner);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(expected.begin(), expected.end(), files.begin(), files.end());\r\n}\r\n\r\nBOOST_AUTO_TEST_CASE(returns_all_text_files)\r\n{\r\n expect_enumerate_text_file();\r\n expect_enumerate_non_text_file();\r\n expect_enumerate_text_file(ARBITRARY_OTHER_TEXT_FILE_NAME);\r\n expect_enumerate_end();\r\n\r\n std::vector files = text_files(ARBITRARY_DIRECTORY_NAME, scanner);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(expected.begin(), expected.end(), files.begin(), files.end());\r\n}\r\n\r\nBOOST_AUTO_TEST_SUITE_END();\r\n//]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/ref-assertion.qbk",
"content": "[/==============================================================================\n Copyright (C) 2013 Richard Thomson\n\n Distributed under the Boost Software License, Version 1.0. (See accompanying\n file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)\n===============================================================================/]\n\n[template operator_warning_for[assertion operator element]\n[important If you get a strange compile error when using [assertion],\ncheck that the appropriate [operator] and `operator<<` are defined for\nthe [element]. If you define these operators in your test\ncode, keep in mind argument-dependent lookup of types based on enclosing\nnamespaces and the namespaces opened by test suites.\nThe need to define `operator<<` can be eliminated by using\n[link test.reference.assertion.boost_test_dont_print_log_value =BOOST_TEST_DONT_PRINT_LOG_VALUE=].]\n]\n\n[template operator_warning[assertion operator]\n[operator_warning_for [assertion] [operator] arguments]\n]\n\n[section:assertion Test Assertions]\n\nAssertions are used to validate the result of exercising the system under\ntest. When an assertion fails, a diagnostic message is created and the\nfailed assertion is recorded. Different assertion levels allow you to\ncontrol how a failed assertion is interpreted by the test runner.\n\n[important When an assertion involves a user-defined datatype, a stream insertion\noperator (`operator<<`) must be defined for the user-defined datatype,\nor the assertion will fail to compile. Asserting a comparison operation\non a value of a user-defined type will require the appropriate comparison\noperator (`operator<`, `operator==`, etc.) be defined for the type or the\nassertion will fail to compile.\nThe need to define `operator<<` can be eliminated by using\n[link test.reference.assertion.boost_test_dont_print_log_value =BOOST_TEST_DONT_PRINT_LOG_VALUE=].\n]\n\nThe [link test.guide.compilation.minimal_header minimal header] test\nframework does not provide the facilities described here.\n\n[section:levels Assertion Levels]\n\nWhen using the library or header-only version of __test__, many\nassertion macros are provided in three levels that determine the behavior\nwhen the assertion fails and how a failed assertion interacts with the\ntest runner.\n\n[table Assertion Levels\n[[Level] [Test Case Fails?] [Aborts Execution?]]\n[[=WARN=] [No] [No]]\n[[=CHECK=] [Yes] [no]]\n[[=REQUIRE=] [Yes] [Yes]]\n]\n\nThe =WARN= level issues a diagnostic message, but the\ntest case is not considered to have failed and continues\nexecuting. The =CHECK= level issues a message to the test log on failure,\nmarks the test case as failed and continues executing. The =REQUIRE=\nlevel issues a message to the test log on failure, marks the test case\nas failed and halts execution of the test case.\n\n[endsect]\n\n[section =BOOST_=[~level]=_BITWISE_EQUAL=]\n\n=BITWISE_=[~level]=_EQUAL(=[~lhs], [~rhs]=)= compares the two arguments\nfor bitwise equality and fails if they are not equal. This can be useful\nwhen testing integral values that represent a logical or combination of\nbit flags.\n\n[heading Example]\n\n[example_bitwise_equal]\n\n[endsect]\n\n[section =BOOST_=[~level]=_CLOSE=]\n\n=BOOST_=[~level]=_CLOSE(=[~lhs], [~rhs], [~tolerance]=)= compares the\ntwo floating-point arguments and considers them equal if they agree within\nthe given [~tolerance]. The [~tolerance] is given as a percentage.\n\n[heading Example]\n\n[example_close]\n\n[/ TODO: link to floating-point algorithm explanation /]\n\n[endsect]\n\n[section =BOOST_=[~level]=_CLOSE_FRACTION=]\n\n=BOOST_=[~level]=_CLOSE_FRACTION(=[~lhs], [~rhs], [~tolerance]=)= compares\nthe two floating-point arguments and considers them equal if they agree\nwithin the given [~tolerance]. The [~tolerance] is given as a percentage.\n\n[heading Example]\n\n[example_close_fraction]\n\n[/ TODO: link to floating-point algorithm explanation /]\n\n[endsect]\n\n[section:boost_level_equal =BOOST_=[~level]=_EQUAL=]\n\n=BOOST_EQUAL(=[~lhs], [~rhs]=)= compares the two arguments with\n`operator==`. The diagnostic message is constructed with `operator<<`\non the two arguments.\n\n[operator_warning =BOOST_EQUAL= `operator==`]\n\n[heading Examples]\n\n[example_equal]\n[example_equal_custom_compare]\n\n[endsect]\n\n[section =BOOST_=[~level]=_EQUAL_COLLECTIONS=]\n\n=BOOST_=[~level]=_EQUAL_COLLECTIONS(=[~lhs_begin], [~lhs_end], [~rhs_begin], [~rhs_end]=)=\ncompares two collections for equality. Two collections are considered\nequal if they have the same number of elements and the elements compare\nequal by `operator==`. The elements are obtained through the supplied\niterators on the collections. The diagnostic message is constructed from\napplying `operator<<` to each of the elements in the collections.\n\n[operator_warning_for =BOOST_EQUAL_COLLECTIONS= `operator==` element type in the collection]\n\n[heading Example]\n\n[example_equal_collections]\n\n[endsect]\n\n[section:boost_level_exception =BOOST_=[~level]=_EXCEPTION=]\n\n=BOOST_=[~level]=_EXCEPTION(=[~expression], [~exception], [~predicate]=)=\nasserts that when [~expression] throws an exception of type [~exception],\nthe [~predicate] applied to the instance of the exception returns =true=.\nThis is used to verify not only that an exception of the correct type was\nthrown, but that the contents of the thrown exception meet the expectations\nof the predicate.\n\nThe [~predicate] can return =bool=, or __predicate_result__ which allows\nthe predicate to build up a detailed failure message.\n\n[heading Example]\n\n[example_exception]\n\n[endsect]\n\n[section:boost_fail =BOOST_FAIL=]\n\n=BOOST_FAIL(=[~message]=)= always fails and emits the given\n[~message] at the =REQUIRE= assertion level. Other assertion macros\nare generally preferred over =BOOST_FAIL= because they emit better\ndiagnostics in the case of failure.\n\nThere are two situations\nwhere you might be tempted to use =BOOST_FAIL=: testing the situations\nwhere the system under test will throw exceptions or comparing against\nthe values computed by the system under test.\nFor testing exception generation, use __boost_require_throw__,\n__boost_require_no_throw__ or __boost_require_exception__.\nFor testing against values computed by the system under test, use the\ncomparing assertions.\n\n[heading Example]\n\n[example_fail]\n\n[endsect]\n\n[section =BOOST_=[~level]=_GE=]\n\n=BOOST_=[~level]=_GE(=[~lhs], [~rhs]=)= asserts that [~lhs] is greater\nthan or equal to [~rhs]. The comparison is made by applying `operator>=`\nto both arguments. The diagnostic message is constructed from applying\n`operator<<` to the two arguments.\n\n[operator_warning =BOOST_=[~level]=_GE= `operator>=`]\n\n[heading Example]\n\n[example_ge]\n\n[endsect]\n\n[section =BOOST_=[~level]=_GT=]\n\n=BOOST_=[~level]=_GT(=[~lhs], [~rhs]=)= asserts that [~lhs] is greater than [~rhs].\nThe comparison is made by applying `operator>` to both arguments.\nThe diagnostic message is constructed from applying `operator<<` to the two arguments.\n\n[operator_warning =BOOST_=[~level]=_GT= `operator>`]\n\n[heading Example]\n\n[example_gt]\n\n[endsect]\n\n[section =BOOST_=[~level]=_LE=]\n\n=BOOST_=[~level]=_LE(=[~lhs], [~rhs]=)= asserts that [~lhs] is less\nthan or equal to [~rhs]. The comparison is made by applying `operator<=`\nto both arguments. The diagnostic message is constructed from applying\n`operator<<` to the two arguments.\n\n[operator_warning =BOOST_=[~level]=_LE= `operator<=`]\n\n[heading Example]\n\n[example_le]\n\n[endsect]\n\n[section =BOOST_=[~level]=_LT=]\n\n=BOOST_=[~level]=_LT(=[~lhs], [~rhs]=)= asserts that [~lhs] is less\nthan [~rhs]. The comparison is made by applying `operator<`\nto both arguments. The diagnostic message is constructed from applying\n`operator<<` to the two arguments.\n\n[operator_warning =BOOST_=[~level]=_LT= `operator<`]\n\n[heading Example]\n\n[example_lt]\n\n[endsect]\n\n[section:boost_level_message =BOOST_=[~level]=_MESSAGE=]\n\n=BOOST_=[~level]=_MESSAGE(=[~predicate], [~message]=)= emits [~message]\nif the supplied [~predicate] evaluates to false. The [~message] is\napplied to an output stream with `operator<<` and the argument can contain\nadditional applications of `operator<<` for building up complex messages.\nThe predicate can return =bool= or __predicate_result__.\n\n[heading Example]\n\n[example_message]\n\n[endsect]\n\n[section =BOOST_=[~level]=_NE=]\n\n=BOOST_=[~level]=_NE(=[~lhs], [~rhs]=)= asserts that [~lhs] is not equal\nto [~rhs]. The comparison is made by applying `operator!=`\nto both arguments. The diagnostic message is constructed from applying\n`operator<<` to the two arguments.\n\n[operator_warning =BOOST_=[~level]=_NE= `operator!=`]\n\n[heading Example]\n\n[example_ne]\n\n[endsect]\n\n[section:boost_level_no_throw =BOOST_=[~level]=_NO_THROW=]\n\n=BOOST_=[~level]=_NO_THROW(=[~expression]=)= asserts that [~expression]\ndoes not throw an exception.\n\n[heading Example]\n\n[example_no_throw]\n\n[endsect]\n\n[section =BOOST_=[~level]=_PREDICATE=]\n\n=BOOST_=[~level]=_PREDICATE(=[~predicate], [~args]=)= asserts that the\nsupplied [~predicate] applied to [~args] evaluates to true. The supplied\n[~predicate] must have a return type of =bool= and argument types that\nare compatible with the argument list [~args]. Because =BOOST_=[~level]=_PREDICATE=\nis a macro, the [~args] must be supplied as a sequence of parenthesized\nvalues, with no comma separating the values.\n\n[heading Example]\n\n[example_predicate]\n\n[endsect]\n\n[section =BOOST_=[~level]=_SMALL=]\n\n=BOOST_=[~level]=_SMALL(=[~value], [~tolerance]=)= checks that the [~value]\nis within [~tolerance] of zero.\n\n[heading Example]\n\n[example_small]\n\n[/ TODO: link to floating-point algorithm explanation /]\n\n[endsect]\n\n[section:boost_level_throw =BOOST_=[~level]=_THROW=]\n\n=BOOST_=[~level]=_THROW(=[~expression], [~exception]=)= asserts that\n[~expression] throws an exception of type [~exception] or a type\nderived from [~exception].\n\n[heading Example]\n\n[example_throw]\n\n[endsect]\n\n[section:boost_test_dont_print_log_value =BOOST_TEST_DONT_PRINT_LOG_VALUE=]\n\n=BOOST_TEST_DONT_PRINT_LOG_VALUE(=[~type]=)= instructs the test framework\nto ignore values of type [~type] when constructing diagnostic messages.\nIt does this by defining an empty implementation of a print function\nspecialized for [~type]. Because the specialization is inside an\nimplementation namespace for __test__, the macro must be invoked at\nthe global namespace scope. Therefore, it cannot be used inside a test\nsuite or any other namespace.\n\n[heading Example]\n\n[example_test_dont_print_log_value]\n\n[endsect]\n\n[endsect]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/ref-assertion.qbk.bak",
"content": "[/==============================================================================\n Copyright (C) 2013 Richard Thomson\n\n Distributed under the Boost Software License, Version 1.0. (See accompanying\n file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)\n===============================================================================/]\n\n[template operator_warning_for[assertion operator element]\n[important If you get a strange compile error when using [assertion],\ncheck that the appropriate [operator] and `operator<<` are defined for\nthe [element]. If you define these operators in your test\ncode, keep in mind argument-dependent lookup of types based on enclosing\nnamespaces and the namespaces opened by test suites.\nThe need to define `operator<<` can be eliminated by using\n[link test.reference.assertion.boost_test_dont_print_log_value =BOOST_TEST_DONT_PRINT_LOG_VALUE=].]\n]\n\n[template operator_warning[assertion operator]\n[operator_warning_for [assertion] [operator] arguments]\n]\n\n[section:assertion Test Assertions]\n\nAssertions are used to validate the result of exercising the system under\ntest. When an assertion fails, a diagnostic message is created and the\nfailed assertion is recorded. Different assertion levels allow you to\ncontrol how a failed assertion is interpreted by the test runner.\n\n[important When an assertion involves a user-defined datatype, a stream insertion\noperator (`operator<<`) must be defined for the user-defined datatype,\nor the assertion will fail to compile. Asserting a comparison operation\non a value of a user-defined type will require the appropriate comparison\noperator (`operator<`, `operator==`, etc.) be defiend for the type or the\nassertion will fail to compile.\nThe need to define `operator<<` can be eliminated by using\n[link test.reference.assertion.boost_test_dont_print_log_value =BOOST_TEST_DONT_PRINT_LOG_VALUE=].\n]\n\nThe [link test.guide.compilation.minimal_header minimal header] test\nframework does not provide the facilities described here.\n\n[section:levels Assertion Levels]\n\nWhen using the library or header-only version of __test__, many\nassertion macros are provided in three levels that determine the behavior\nwhen the assertion fails and how a failed assertion interacts with the\ntest runner.\n\n[table Assertion Levels\n[[Level] [Test Case Fails?] [Aborts Execution?]]\n[[=WARN=] [No] [No]]\n[[=CHECK=] [Yes] [no]]\n[[=REQUIRE=] [Yes] [Yes]]\n]\n\nThe =WARN= level issues a diagnostic message, but the\ntest case is not considered to have failed and continues\nexecuting. The =CHECK= level issues a message to the test log on failure,\nmarks the test case as failed and continues executing. The =REQUIRE=\nlevel issues a message to the test log on failure, marks the test case\nas failed and halts execution of the test case.\n\n[endsect]\n\n[section =BOOST_=[~level]=_BITWISE_EQUAL=]\n\n=BITWISE_=[~level]=_EQUAL(=[~lhs], [~rhs]=)= compares the two arguments\nfor bitwise equality and fails if they are not equal. This can be useful\nwhen testing integral values that represent a logical or combination of\nbit flags.\n\n[heading Example]\n\n[example_bitwise_equal]\n\n[endsect]\n\n[section =BOOST_=[~level]=_CLOSE=]\n\n=BOOST_=[~level]=_CLOSE(=[~lhs], [~rhs], [~tolerance]=)= compares the\ntwo floating-point arguments and considers them equal if they agree within\nthe given [~tolerance]. The [~tolerance] is given as a percentage.\n\n[heading Example]\n\n[example_close]\n\n[/ TODO: link to floating-point algorithm explanation /]\n\n[endsect]\n\n[section =BOOST_=[~level]=_CLOSE_FRACTION=]\n\n=BOOST_=[~level]=_CLOSE_FRACTION(=[~lhs], [~rhs], [~tolerance]=)= compares\nthe two floating-point arguments and considers them equal if they agree\nwithin the given [~tolerance]. The [~tolerance] is given as a percentage.\n\n[heading Example]\n\n[example_close_fraction]\n\n[/ TODO: link to floating-point algorithm explanation /]\n\n[endsect]\n\n[section:boost_level_equal =BOOST_=[~level]=_EQUAL=]\n\n=BOOST_EQUAL(=[~lhs], [~rhs]=)= compares the two arguments with\n`operator==`. The diagnostic message is constructed with `operator<<`\non the two arguments.\n\n[operator_warning =BOOST_EQUAL= `operator==`]\n\n[heading Examples]\n\n[example_equal]\n[example_equal_custom_compare]\n\n[endsect]\n\n[section =BOOST_=[~level]=_EQUAL_COLLECTIONS=]\n\n=BOOST_=[~level]=_EQUAL_COLLECTIONS(=[~lhs_begin], [~lhs_end], [~rhs_begin], [~rhs_end]=)=\ncompares two collections for equality. Two collections are considered\nequal if they have the same number of elements and the elements compare\nequal by `operator==`. The elements are obtained through the supplied\niterators on the collections. The diagnostic message is constructed from\napplying `operator<<` to each of the elements in the collections.\n\n[operator_warning_for =BOOST_EQUAL_COLLECTIONS= `operator==` element type in the collection]\n\n[heading Example]\n\n[example_equal_collections]\n\n[endsect]\n\n[section:boost_level_exception =BOOST_=[~level]=_EXCEPTION=]\n\n=BOOST_=[~level]=_EXCEPTION(=[~expression], [~exception], [~predicate]=)=\nasserts that when [~expression] throws an exception of type [~exception],\nthe [~predicate] applied to the instance of the exception returns =true=.\nThis is used to verify not only that an exception of the correct type was\nthrown, but that the contents of the thrown exception meet the expectations\nof the predicate.\n\nThe [~predicate] can return =bool=, or __predicate_result__ which allows\nthe predicate to build up a detailed failure message.\n\n[heading Example]\n\n[example_exception]\n\n[endsect]\n\n[section:boost_fail =BOOST_FAIL=]\n\n=BOOST_FAIL(=[~message]=)= always fails and emits the given\n[~message] at the =REQUIRE= assertion level. Other assertion macros\nare generally preferred over =BOOST_FAIL= because they emit better\ndiagnostics in the case of failure.\n\nThere are two situations\nwhere you might be tempted to use =BOOST_FAIL=: testing the situations\nwhere the system under test will throw exceptions or comparing against\nthe values computed by the system under test.\nFor testing exception generation, use __boost_require_throw__,\n__boost_require_no_throw__ or __boost_require_exception__.\nFor testing against values computed by the system under test, use the\ncomparing assertions.\n\n[heading Example]\n\n[example_fail]\n\n[endsect]\n\n[section =BOOST_=[~level]=_GE=]\n\n=BOOST_=[~level]=_GE(=[~lhs], [~rhs]=)= asserts that [~lhs] is greater\nthan or equal to [~rhs]. The comparison is made by applying `operator>=`\nto both arguments. The diagnostic message is constructed from applying\n`operator<<` to the two arguments.\n\n[operator_warning =BOOST_=[~level]=_GE= `operator>=`]\n\n[heading Example]\n\n[example_ge]\n\n[endsect]\n\n[section =BOOST_=[~level]=_GT=]\n\n=BOOST_=[~level]=_GT(=[~lhs], [~rhs]=)= asserts that [~lhs] is greater than [~rhs].\nThe comparison is made by applying `operator>` to both arguments.\nThe diagnostic message is constructed from applying `operator<<` to the two arguments.\n\n[operator_warning =BOOST_=[~level]=_GT= `operator>`]\n\n[heading Example]\n\n[example_gt]\n\n[endsect]\n\n[section =BOOST_=[~level]=_LE=]\n\n=BOOST_=[~level]=_LE(=[~lhs], [~rhs]=)= asserts that [~lhs] is less\nthan or equal to [~rhs]. The comparison is made by applying `operator<=`\nto both arguments. The diagnostic message is constructed from applying\n`operator<<` to the two arguments.\n\n[operator_warning =BOOST_=[~level]=_LE= `operator<=`]\n\n[heading Example]\n\n[example_le]\n\n[endsect]\n\n[section =BOOST_=[~level]=_LT=]\n\n=BOOST_=[~level]=_LT(=[~lhs], [~rhs]=)= asserts that [~lhs] is less\nthan [~rhs]. The comparison is made by applying `operator<`\nto both arguments. The diagnostic message is constructed from applying\n`operator<<` to the two arguments.\n\n[operator_warning =BOOST_=[~level]=_LT= `operator<`]\n\n[heading Example]\n\n[example_lt]\n\n[endsect]\n\n[section:boost_level_message =BOOST_=[~level]=_MESSAGE=]\n\n=BOOST_=[~level]=_MESSAGE(=[~predicate], [~message]=)= emits [~message]\nif the supplied [~predicate] evaluates to false. The [~message] is\napplied to an output stream with `operator<<` and the argument can contain\nadditional applications of `operator<<` for building up complex messages.\nThe predicate can return =bool= or __predicate_result__.\n\n[heading Example]\n\n[example_message]\n\n[endsect]\n\n[section =BOOST_=[~level]=_NE=]\n\n=BOOST_=[~level]=_NE(=[~lhs], [~rhs]=)= asserts that [~lhs] is not equal\nto [~rhs]. The comparison is made by applying `operator!=`\nto both arguments. The diagnostic message is constructed from applying\n`operator<<` to the two arguments.\n\n[operator_warning =BOOST_=[~level]=_NE= `operator!=`]\n\n[heading Example]\n\n[example_ne]\n\n[endsect]\n\n[section:boost_level_no_throw =BOOST_=[~level]=_NO_THROW=]\n\n=BOOST_=[~level]=_NO_THROW(=[~expression]=)= asserts that [~expression]\ndoes not throw an exception.\n\n[heading Example]\n\n[example_no_throw]\n\n[endsect]\n\n[section =BOOST_=[~level]=_PREDICATE=]\n\n=BOOST_=[~level]=_PREDICATE(=[~predicate], [~args]=)= asserts that the\nsupplied [~predicate] applied to [~args] evaluates to true. The supplied\n[~predicate] must have a return type of =bool= and argument types that\nare compatible with the argument list [~args]. Because =BOOST_=[~level]=_PREDICATE=\nis a macro, the [~args] must be supplied as a sequence of parenthesized\nvalues, with no comma separating the values.\n\n[heading Example]\n\n[example_predicate]\n\n[endsect]\n\n[section =BOOST_=[~level]=_SMALL=]\n\n=BOOST_=[~level]=_SMALL(=[~value], [~tolerance]=)= checks that the [~value]\nis within [~tolerance] of zero.\n\n[heading Example]\n\n[example_small]\n\n[/ TODO: link to floating-point algorithm explanation /]\n\n[endsect]\n\n[section:boost_level_throw =BOOST_=[~level]=_THROW=]\n\n=BOOST_=[~level]=_THROW(=[~expression], [~exception]=)= asserts that\n[~expression] throws an exception of type [~exception] or a type\nderived from [~exception].\n\n[heading Example]\n\n[example_throw]\n\n[endsect]\n\n[section:boost_test_dont_print_log_value =BOOST_TEST_DONT_PRINT_LOG_VALUE=]\n\n=BOOST_TEST_DONT_PRINT_LOG_VALUE(=[~type]=)= instructs the test framework\nto ignore values of type [~type] when constructing diagnostic messages.\nIt does this by defining an empty implementation of a print function\nspecialized for [~type]. Because the specialization is inside an\nimplementation namespace for __test__, the macro must be invoked at\nthe global namespace scope. Therefore, it cannot be used inside a test\nsuite or any other namespace.\n\n[heading Example]\n\n[example_test_dont_print_log_value]\n\n[endsect]\n\n[endsect]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/ref-compilation.qbk",
"content": "[/==============================================================================\n Copyright (C) 2013 Richard Thomson\n\n Distributed under the Boost Software License, Version 1.0. (See accompanying\n file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)\n===============================================================================/]\n\n[section Configuration Macros]\n\n[table\n[[Macro] [Meaning]]\n[[[#test.reference.compilation.boost_test_alternative_init_api]=BOOST_TEST_ALTERNATIVE_INIT_API=]\n [When defined, the alternative [link test.reference.test_classes.init_unit_test_func =init_unit_test_func=] test module initialization API is used.]]\n[[[#test.reference.compilation.boost_test_dyn_link]=BOOST_TEST_DYN_LINK=]\n [When defined, the implementation is compiled as a shared library.\n Defining =BOOST_TEST_DYN_LINK= also defines\n =BOOST_TEST_ALTERNATIVE_INIT_API=.]]\n[[[#test.reference.compilation.boost_test_main]=BOOST_TEST_MAIN=]\n [When defined, an implementation of main is included in the source file.]]\n[[[#test.reference.compilation.boost_test_module]=BOOST_TEST_MODULE=]\n [When defined, it provides the name of the master test suite,\n otherwise a default name is used.]]\n[[[#test.reference.compilation.boost_test_no_lib]=BOOST_TEST_NO_LIB=]\n [When defined, no automatic linking is performed.]]\n[[[#test.reference.compilation.boost_test_no_main]=BOOST_TEST_NO_MAIN=]\n [When defined, no implementation of main is provided in any configuration.\n Static and shared libraries must have been built with this symbol\n defined for it to take effect when using the library. The test\n executable must provide its own implementation of =main=;\n [link test.reference.test_classes.unit_test_main =unit_test_main=] may\n be used for this purpose.]]\n]\n\nWhen using any of these macros, they must be defined before including any\nheader from __test__.\n\n[endsect]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/ref-runner-argument.qbk",
"content": "[/==============================================================================\n Copyright (C) 2013 Richard Thomson\n\n Distributed under the Boost Software License, Version 1.0. (See accompanying\n file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)\n===============================================================================/]\n\n[template envar[name]\n[*Environment variable]: [^[name]]\n]\n\n[section:argument Command Line Arguments]\n\n[table Command Line Argument Summary\n[[Argument] [Description]]\n[[=--auto_start_dbg=] [Automatically attach debugger in case of system failure]]\n[[=--build_info=] [Print build information]]\n[[=--catch_system_errors=] [Catch system errors]]\n[[=--detect_fp_exceptions=] [Detect floating-point exceptions]]\n[[=--detect_memory_leaks=] [Detect memory leaks]]\n[[=--help=] [Print out a summary of test runner options]]\n[[=--log_format=] [The format of the test log]]\n[[=--log_level=] [The level of logging reported]]\n[[=--log_sink=] [The log sink name]]\n[[=--output_format=] [The output format]]\n[[=--random=] [Random number seed]]\n[[=--report_format=] [The test results report format]]\n[[=--report_level=] [The test results report level]]\n[[=--report_sink=] [The report sink name]]\n[[=--result_code=] [Return result code]]\n[[=--run_test=] [Tests to run]]\n[[=--show_progress=] [Show execution progress]]\n[[=--use_alt_stack=] [Use alternative stack]]\n[[=--wait_for_debugger=] [Wait for the debugger to attach to the test runner.]]\n]\n\nThe functionality of each command-line option can also be invoked with an\nenvironment variable. The description for each option gives the environment\nvariable associated with that option.\n\n[section:auto_start_dbg =--auto_start_dbg=]\n\nThis argument controls whether or not a debugger is attached to the test\nrunner when a fatal system error occurs. A fatal system error includes\nUnix/POSIX signals, C++ exceptions and Win32 structured exceptions.\n\n[table\n[[Value] [Meaning]]\n[[[*=no=] (default)] [Do not attach a debugger to when a fatal system error occurs.]]\n[[=yes=] [Attach the default debugger when a fatal system error occurs.]]\n]\n\n[envar BOOST_TEST_AUTO_START_DBG]\n\n[endsect]\n\n[section =--build_info=]\n\nThis argument causes the test runner to report information about the\nbuild environment before running the tests. If the argument is specified\nbut no value is given, then a value of =yes= is assumed.\n\n[table\n[[Value] [Meaning]]\n[[[*=no=] (default)] [Do not report build information.]]\n[[=yes=] [Report build information.]]\n]\n\n[envar BOOST_TEST_BUILD_INFO]\n\n[endsect]\n\n[section =--catch_system_errors=]\n\nThis argument controls whether or not the test runner catches fatal system\nerrors.\n\n[table\n[[Value] [Meaning]]\n[[=no=] [Do not handle fatal system errors.]]\n[[[*=yes=] (default)] [Handle fatal system errors.]]\n]\n\n[envar BOOST_TEST_CATCH_SYSTEM_ERRORS]\n\n[endsect]\n\n[section =--detect_fp_exceptions=]\n\nIf the execution environment supports floating-point exceptions, this\nargument controls whether or not the test runner will detect floating-point\nexceptions.\n\n[table\n[[Value] [Meaning]]\n[[[*=no=] (default)] [Do not detect floating-point exceptions.]]\n[[=yes=] [Detect floating-point exceptions, if supported.]]\n]\n\n[envar BOOST_TEST_DETECT_FP_EXCEPTIONS]\n\n[endsect]\n\n[section =--detect_memory_leaks=]\n\nIf the execution environment supports the detection of memory leaks,\nthis argument controls whether or not the test runner reports memory leaks.\nAfter running the tests, a memory leak report is issued showing the allocation\nnumber and the amount of memory leaked.\n\nValues greater than =1= for this argument cause a trap to the debugger for\na particular memory allocation number. Currently, this option is only\nimplemented for Microsoft compilers.\n\n[table\n[[Value] [Meaning]]\n[[=0=] [Do not detect memory leaks.]]\n[[[*=1=] (default)] [Detect memory leaks and issue a memory leak report.]]\n[[[~number]] [Break on allocation [~number].]]\n]\n\n[envar BOOST_TEST_DETECT_MEMORY_LEAKS]\n\n[endsect]\n\n[section:log_format =--log_format=]\n\nThis argument controls the format of the test runner output. The value\nis case insensitive. See [link test.reference.runner.output.log test\nrunner log] for more information on the log.\n\n[table\n[[Value] [Meaning]]\n[[[*=HRF=] (default)] [Human readable format output.]]\n[[=XML=] [XML format output.]]\n]\n\n[envar BOOST_TEST_LOG_FORMAT]\n\n[endsect]\n\n[section:log_level =--log_level=]\n\nThis argument controls the level of test runner output. The values are\ncumulative, with each increase in log level including all messages at\nlower levels. By default, only errors are reported.\nSee [link test.reference.runner.output.log test\nrunner log] for more information on the log.\n\n[table\n[[Value] [Meaning]]\n[[=nothing=] [Do not report any information.]]\n[[=fatal_error=] [Report all user or system fatal errors, such as memory access violation.]]\n[[=system_error=] [Report system non-fatal errors, such as timeout or floating-point exception.]]\n[[=cpp_exception=] [Report uncaught C++ exceptions.]]\n[[[*=error=] (default)] [Report test failures.]]\n[[=warning=] [Report test warnings.]]\n[[=message=] [Report test messages; see __boost_test_message__.]]\n[[=test_suite=] [Report entering and leaving every test case and test suite.]]\n[[=success=] [Report all successful assertions.]]\n[[=all=] [Report everything.]]\n]\n\n[envar BOOST_TEST_LOG_LEVEL]\n\n[endsect]\n\n[section:log_sink =--log_sink=]\n\nThis argument controls the destination, or sink, of the test runner log.\nSee [link test.reference.runner.output.log test\nrunner log] for more information on the log.\n\n[table\n[[Value] [Meaning]]\n[[[*=stdout=] (default)] [The test runner log is sent to the standard output stream.]]\n[[=stderr=] [The test runner log is sent to the standard error stream.]]\n[[[~file]] [The test runner log is sent to the file [~file].]]\n]\n\n[envar BOOST_TEST_LOG_SINK]\n\n[endsect]\n\n[section:output_format =--output_format=]\n\nThis argument combines __log_format__ and __report_format__.\nSee [link test.reference.runner.output.log test\nrunner log] for more information on the log.\nSee [link test.reference.runner.output.report test\nrunner report] for more information on the report.\n\n[table\n[[Value] [Meaning]]\n[[[*=HRF=] (default)] [Human readable format output.]]\n[[=XML=] [XML format output.]]\n]\n\n[envar BOOST_TEST_OUTPUT_FORMAT]\n\n[endsect]\n\n[section =--random=]\n\nThis argument controls whether or not the test runner will execute tests\nin a random order. This argument can also provide a seed for the random\nnumber generator used to run tests in a random order.\n\n[table\n[[Value] [Meaning]]\n[[[*=0=] (default)] [Run tests in registration order.]]\n[[=1=] [Run tests in a random order, using the current time as the seed.]]\n[[[~n]] [Run tests in a random order, using [~n] as the seed.]]\n]\n\n[envar BOOST_TEST_RANDOM]\n\n[endsect]\n\n[section:report_format =--report_format=]\n\nThis argument controls the format of the test report.\nSee [link test.reference.runner.output.report test\nrunner report] for more information on the report.\n\n[table\n[[Value] [Meaning]]\n[[[*=HRF=] (default)] [Human readable format output.]]\n[[=XML=] [XML format output.]]\n]\n\n[envar BOOST_TEST_REPORT_FORMAT]\n\n[endsect]\n\n[section:report_level =--report_level=]\n\nThis argument controls the level of the test report. The levels are\ncumulative, with each successive level incorporating the output of all\nthe previous levels.\nSee [link test.reference.runner.output.report test\nrunner report] for more information on the report.\n\n[table\n[[Value] [Meaning]]\n[[=no=] [No test report.]]\n[[[*=confirm=] (default)] [Confirmation test report.]]\n[[=short=] [Short test report.]]\n[[=detailed=] [Detailed test report.]]\n]\n\n[envar BOOST_TEST_REPORT_LEVEL]\n\n[endsect]\n\n[section:report_sink =--report_sink=]\n\nThis argument controls the destination, or sink, of the test runner report.\nSee [link test.reference.runner.output.report test\nrunner report] for more information on the report.\n\n[table\n[[Value] [Meaning]]\n[[=stdout=] [The test report is sent to the standard output stream.]]\n[[[*=stderr=] (default)] [The test report is sent to the standard error stream.]]\n[[[~file]] [The test report is sent to the file [~file].]]\n]\n\n[envar BOOST_TEST_REPORT_SINK]\n\n[endsect]\n\n[section =--result_code=]\n\nThis argument controls whether or not the test runner returns an exit\ncode corresponding to a summary of the test execution or zero. The summary\nresult code is determined as follows:\n\n[table\n[[Result Code] [Description]]\n[[0 (=boost::exit_success=)] [All executed tests passed.]]\n[[200 (=boost::exit_exception_failure=)] [Failure due to uncaught exception.]]\n[[201 (=boost::exit_test_failure=)] [One or more executed tests failed.]]\n]\n\n[table\n[[Value] [Meaning]]\n[[=no=] [Always return zero.]]\n[[[*=yes=] (default)] [Return a status code indicating the summary of the tests executed.]]\n]\n\n[envar BOOST_TEST_RESULT_CODE]\n\n[endsect]\n\n[section:run_test =--run_test=]\n\nThis argument controls which test cases will be executed. The value is\na comma separated list of test specifiers. Test cases are arranged as\nleaves on a tree structure, with every test case belonging to a test suite.\nThe test runner always creates a master test suite. Named test suites are\nchildren of the master test suite or another named test suite. Any test\ncase that is not the child of a named test suite is a child of the unnamed\nmaster test suite.\n\nTest specifiers select test cases or suites by naming the path from the\nunnamed master test suite to the case or suite, similar to a full path to\na file in a hierarchical directory structure. A test specifier is one or\nmore path specifiers, separated by a slash (=/=). A test specifier begins\nat the master test suite and proceeds down the test tree, naming suites or\ntest cases.\n\nThe argument __report_level__ set to =detailed= can be used to output the\nnames of all the test suites and test cases within those test suites.\n\n[table\n[[Path Specifier] [Tests Selected]]\n[[[~name]] [The test case or suite named [~name].]]\n[[=*=[~name]] [All test cases or suites whose name ends in [~name].]]\n[[[~name]=*=] [All test cases or suites whose name begins with [~name].]]\n[[=*=[~name]=*=] [All test cases or suites whose name contains [~name].]]\n[[=*=] [All test cases or suites.]]\n[[[~spec1]=,=[~spec2]=,=[~...]] [The test cases or suites with the given specifier.]]\n[[[~spec1]=/=[~spec2]] [The test cases or suites matched by [~spec2] in the\n test suite matched by [~spec1].]]\n]\n\n[envar BOOST_TESTS_TO_RUN]\n\n[endsect]\n\n[section =--show_progress=]\n\nThis parameter instructs the test runner to print progress through the\ntest cases. The test runner has no way of determining the length of time\neach test case will consume; the progress percentage is determined by\ncounting test cases.\n\n[table\n[[Value] [Meaning]]\n[[[*=no=] (default)] [Do not show test execution progress.]]\n[[=yes=] [Show test execution progress.]]\n]\n\n[envar BOOST_TEST_SHOW_PROGRESS]\n\n[endsect]\n\n[section =--use_alt_stack=]\n\nThis parameter instructs the test runner to use an alternate stack for\nsignals processing on platforms where this is supported.\n\n[table\n[[Value] [Meaning]]\n[[[*=no=] (default)] [Do not use an alternate stack.]]\n[[=yes=] [Use an alternate stack, where supported.]]\n]\n\n[envar BOOST_TEST_USE_ALT_STACK]\n\n[endsect]\n\n[endsect]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/ref-runner-argument.qbk.bak",
"content": "[/==============================================================================\n Copyright (C) 2013 Richard Thomson\n\n Distributed under the Boost Software License, Version 1.0. (See accompanying\n file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)\n===============================================================================/]\n\n[template envar[name]\n[*Environment variable]: [^[name]]\n]\n\n[section:argument Command Line Arguments]\n\n[table Command Line Argument Summary\n[[Argument] [Description]]\n[[=--auto_start_dbg=] [Automatically attach debugger in case of system failure]]\n[[=--build_info=] [Print build information]]\n[[=--catch_system_errors=] [Catch system errors]]\n[[=--detect_fp_exceptions=] [Detect floating-point exceptions]]\n[[=--detect_memory_leaks=] [Detect memory leaks]]\n[[=--help=] [Print out a summary of test runner options]]\n[[=--log_format=] [The format of the test log]]\n[[=--log_level=] [The level of logging reported]]\n[[=--log_sink=] [The log sink name]]\n[[=--output_format=] [The output format]]\n[[=--random=] [Random number seed]]\n[[=--report_format=] [The test results report format]]\n[[=--report_level=] [The test results report level]]\n[[=--report_sink=] [The report sink name]]\n[[=--result_code=] [Return result code]]\n[[=--run_test=] [Tests to run]]\n[[=--show_progress=] [Show execution progress]]\n[[=--use_alt_stack=] [Use alternative stack]]\n[[=--wait_for_debugger=] [Wait for the debugger to attach to the test runner.]]\n]\n\nThe functionality of each command-line option can also be invoked with an\nenvironment variable. The description for each option gives the environment\nvariable associated with that option.\n\n[section:auto_start_dbg =--auto_start_dbg=]\n\nThis argument controls whether or not a debugger is attached to the test\nrunner when a fatal system error occurs. A fatal system error includes\nUnix/POSIX signals, C++ exceptions and Win32 structured exceptions.\n\n[table\n[[Value] [Meaning]]\n[[[*=no=] (default)] [Do not attach a debugger to when a fatal system error occurs.]]\n[[=yes=] [Attach the default debugger when a fatal system error occurs.]]\n]\n\n[envar BOOST_TEST_AUTO_START_DBG]\n\n[endsect]\n\n[section =--build_info=]\n\nThis argument causes the test runner to report information about the\nbuild environment before running the tests. If the argument is specified\nbut no value is given, then a value of =yes= is assumed.\n\n[table\n[[Value] [Meaning]]\n[[[*=no=] (default)] [Do not report build information.]]\n[[=yes=] [Report build information.]]\n]\n\n[envar BOOST_TEST_BUILD_INFO]\n\n[endsect]\n\n[section =--catch_system_errors=]\n\nThis argument controls whether or not the test runner catches fatal system\nerrors.\n\n[table\n[[Value] [Meaning]]\n[[=no=] [Do not handle fatal system errors.]]\n[[[*=yes=] (default)] [Handle fatal system errors.]]\n]\n\n[envar BOOST_TEST_CATCH_SYSTEM_ERRORS]\n\n[endsect]\n\n[section =--detect_fp_exceptions=]\n\nIf the execution environment supoprts floating-point exceptions, this\nargument controls whether or not the test runner will detect floating-point\nexceptions.\n\n[table\n[[Value] [Meaning]]\n[[[*=no=] (default)] [Do not detect floating-point exceptions.]]\n[[=yes=] [Detect floating-point exceptions, if supported.]]\n]\n\n[envar BOOST_TEST_DETECT_FP_EXCEPTIONS]\n\n[endsect]\n\n[section =--detect_memory_leaks=]\n\nIf the execution environment supports the detection of memory leaks,\nthis argument controls whether or not the test runner reports memory leaks.\nAfter running the tests, a memory leak report is issued showing the allocation\nnumber and the amount of memory leaked.\n\nValues greater than =1= for this argument cause a trap to the debugger for\na particular memory allocation number. Currently, this option is only\nimplemented for Microsoft compilers.\n\n[table\n[[Value] [Meaning]]\n[[=0=] [Do not detect memory leaks.]]\n[[[*=1=] (default)] [Detect memory leaks and issue a memory leak report.]]\n[[[~number]] [Break on allocation [~number].]]\n]\n\n[envar BOOST_TEST_DETECT_MEMORY_LEAKS]\n\n[endsect]\n\n[section:log_format =--log_format=]\n\nThis argument controls the format of the test runner output. The value\nis case insensitive. See [link test.reference.runner.output.log test\nrunner log] for more information on the log.\n\n[table\n[[Value] [Meaning]]\n[[[*=HRF=] (default)] [Human readable format output.]]\n[[=XML=] [XML format output.]]\n]\n\n[envar BOOST_TEST_LOG_FORMAT]\n\n[endsect]\n\n[section:log_level =--log_level=]\n\nThis argument controls the level of test runner output. The values are\ncumulative, with each increase in log level including all messages at\nlower levels. By default, only errors are reported.\nSee [link test.reference.runner.output.log test\nrunner log] for more information on the log.\n\n[table\n[[Value] [Meaning]]\n[[=nothing=] [Do not report any information.]]\n[[=fatal_error=] [Report all user or system fatal errors, such as memory access violation.]]\n[[=system_error=] [Report system non-fatal errors, such as timeout or floating-point exception.]]\n[[=cpp_exception=] [Report uncaught C++ exceptions.]]\n[[[*=error=] (default)] [Report test failures.]]\n[[=warning=] [Report test warnings.]]\n[[=message=] [Report test messages; see __boost_test_message__.]]\n[[=test_suite=] [Report entering and leaving every test case and test suite.]]\n[[=success=] [Report all successful assertions.]]\n[[=all=] [Report everything.]]\n]\n\n[envar BOOST_TEST_LOG_LEVEL]\n\n[endsect]\n\n[section:log_sink =--log_sink=]\n\nThis argument controls the destination, or sink, of the test runner log.\nSee [link test.reference.runner.output.log test\nrunner log] for more information on the log.\n\n[table\n[[Value] [Meaning]]\n[[[*=stdout=] (default)] [The test runner log is sent to the standard output stream.]]\n[[=stderr=] [The test runner log is sent to the standard error stream.]]\n[[[~file]] [The test runner log is sent to the file [~file].]]\n]\n\n[envar BOOST_TEST_LOG_SINK]\n\n[endsect]\n\n[section:output_format =--output_format=]\n\nThis argument combines __log_format__ and __report_format__.\nSee [link test.reference.runner.output.log test\nrunner log] for more information on the log.\nSee [link test.reference.runner.output.report test\nrunner report] for more information on the report.\n\n[table\n[[Value] [Meaning]]\n[[[*=HRF=] (default)] [Human readable format output.]]\n[[=XML=] [XML format output.]]\n]\n\n[envar BOOST_TEST_OUTPUT_FORMAT]\n\n[endsect]\n\n[section =--random=]\n\nThis argument controls whether or not the test runner will execute tests\nin a random order. This argument can also provide a seed for the random\nnumber generator used to run tests in a random order.\n\n[table\n[[Value] [Meaning]]\n[[[*=0=] (default)] [Run tests in registration order.]]\n[[=1=] [Run tests in a random order, using the current time as the seed.]]\n[[[~n]] [Run tests in a random order, using [~n] as the seed.]]\n]\n\n[envar BOOST_TEST_RANDOM]\n\n[endsect]\n\n[section:report_format =--report_format=]\n\nThis argument controls the format of the test report.\nSee [link test.reference.runner.output.report test\nrunner report] for more information on the report.\n\n[table\n[[Value] [Meaning]]\n[[[*=HRF=] (default)] [Human readable format output.]]\n[[=XML=] [XML format output.]]\n]\n\n[envar BOOST_TEST_REPORT_FORMAT]\n\n[endsect]\n\n[section:report_level =--report_level=]\n\nThis argument controls the level of the test report. The levels are\ncumulative, with each successive level incorporating the output of all\nthe previous levels.\nSee [link test.reference.runner.output.report test\nrunner report] for more information on the report.\n\n[table\n[[Value] [Meaning]]\n[[=no=] [No test report.]]\n[[[*=confirm=] (default)] [Confirmation test report.]]\n[[=short=] [Short test report.]]\n[[=detailed=] [Detailed test report.]]\n]\n\n[envar BOOST_TEST_REPORT_LEVEL]\n\n[endsect]\n\n[section:report_sink =--report_sink=]\n\nThis argument controls the destination, or sink, of the test runner report.\nSee [link test.reference.runner.output.report test\nrunner report] for more information on the report.\n\n[table\n[[Value] [Meaning]]\n[[=stdout=] [The test report is sent to the standard output stream.]]\n[[[*=stderr=] (default)] [The test report is sent to the standard error stream.]]\n[[[~file]] [The test report is sent to the file [~file].]]\n]\n\n[envar BOOST_TEST_REPORT_SINK]\n\n[endsect]\n\n[section =--result_code=]\n\nThis argument controls whether or not the test runner returns an exit\ncode corresponding to a summary of the test execution or zero. The summary\nresult code is determined as follows:\n\n[table\n[[Result Code] [Description]]\n[[0 (=boost::exit_success=)] [All executed tests passed.]]\n[[200 (=boost::exit_exception_failure=)] [Failure due to uncaught exception.]]\n[[201 (=boost::exit_test_failure=)] [One or more executed tests failed.]]\n]\n\n[table\n[[Value] [Meaning]]\n[[=no=] [Always return zero.]]\n[[[*=yes=] (default)] [Return a status code indicating the summary of the tests executed.]]\n]\n\n[envar BOOST_TEST_RESULT_CODE]\n\n[endsect]\n\n[section:run_test =--run_test=]\n\nThis argument controls which test cases will be executed. The value is\na comma separated list of test specifiers. Test cases are arranged as\nleaves on a tree structure, with every test case belonging to a test suite.\nThe test runner always creates a master test suite. Named test suites are\nchildren of the master test suite or another named test suite. Any test\ncase that is not the child of a named test suite is a child of the unnamed\nmaster test suite.\n\nTest specifiers select test cases or suites by naming the path from the\nunnamed master test suite to the case or suite, similar to a full path to\na file in a hierarchical directory structure. A test specifier is one or\nmore path specifiers, separated by a slash (=/=). A test specifier begins\nat the master test suite and proceeds down the test tree, naming suites or\ntest cases.\n\nThe argument __report_level__ set to =detailed= can be used to output the\nnames of all the test suites and test cases within those test suites.\n\n[table\n[[Path Specifier] [Tests Selected]]\n[[[~name]] [The test case or suite named [~name].]]\n[[=*=[~name]] [All test cases or suites whose name ends in [~name].]]\n[[[~name]=*=] [All test cases or suites whose name begins with [~name].]]\n[[=*=[~name]=*=] [All test cases or suites whose name contains [~name].]]\n[[=*=] [All test cases or suites.]]\n[[[~spec1]=,=[~spec2]=,=[~...]] [The test cases or suites with the given specifier.]]\n[[[~spec1]=/=[~spec2]] [The test cases or suites matched by [~spec2] in the\n test suite matched by [~spec1].]]\n]\n\n[envar BOOST_TESTS_TO_RUN]\n\n[endsect]\n\n[section =--show_progress=]\n\nThis parameter instructs the test runner to print progress through the\ntest cases. The test runner has no way of determining the length of time\neach test case will consume; the progress percentage is determined by\ncounting test cases.\n\n[table\n[[Value] [Meaning]]\n[[[*=no=] (default)] [Do not show test execution progress.]]\n[[=yes=] [Show test execution progress.]]\n]\n\n[envar BOOST_TEST_SHOW_PROGRESS]\n\n[endsect]\n\n[section =--use_alt_stack=]\n\nThis parameter instructs the test runner to use an alternate stack for\nsignals processing on platforms where this is supported.\n\n[table\n[[Value] [Meaning]]\n[[[*=no=] (default)] [Do not use an alternate stack.]]\n[[=yes=] [Use an alternate stack, where supported.]]\n]\n\n[envar BOOST_TEST_USE_ALT_STACK]\n\n[endsect]\n\n[endsect]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/ref-runner-output.qbk",
"content": "[/==============================================================================\n Copyright (C) 2013 Richard Thomson\n\n Distributed under the Boost Software License, Version 1.0. (See accompanying\n file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)\n===============================================================================/]\n\n[section:output Test Output]\n\n[section:log Test Log]\n\nThe test log contains detailed information on every assertion in every test\ncase.\nThe log can be formatted as plain human readable text or as XML and can be\nsent to the standard output stream, the standard error stream or a file.\n\nThe amount of detail in the log is set with the __log_level__ option.\nThe format of the log is set with the __log_format__ option.\nThe destination of the log is set with the __log_sink__ option.\nThe __output_format__ option sets both the log format and the report format.\n\nThe XML format for the test log conforms to the schema\n[@boost:/libs/test/doc/src/UTF.log.xsd UTF.log.xsd].\n\n[endsect]\n\n[section:report Test Report]\n\nThe report contains summary information about the test cases\nexecuted and the count of failures.\nThe report can be formatted as plain human readable text or as XML and can be\nsent to the standard output stream, standard error stream or a file.\n\nThe amount of detail in the report is controlled by the __report_level__\noption.\nThe format of the report can be changed with the __report_format__ option.\nThe destination of the report can be set with the __report_sink__ option.\nThe __output_format__ option sets both the report format and the log format.\n\nThe XML format for the test report conforms to the schema\n[@boost:/libs/test/doc/src/UTF.report.xsd UTF.report.xsd].\n\n[endsect]\n\n[section:boost_test_checkpoint =BOOST_TEST_CHECKPOINT=]\n\n=BOOST_TEST_CHECKPOINT(=[~message]=)= registers a test case checkpoint\nand associated [~message] with the test runner. A checkpoint includes\nthe source file and line number where the macro was invoked.\nIf the test case is aborted unexpectedly, the source location and\nmessage associated with the last registered checkpoint is emitted into\nthe log. Checkpoints can be used to identify the location of an unexpected\nfailure within a block of test case code. The [~message] is applied to\nan output stream with `operator<<` and can include other invocations of\n`operator<<`.\n\n[example_checkpoint]\n\n[endsect]\n\n[section:boost_test_message =BOOST_TEST_MESSAGE=]\n\n=BOOST_TEST_MESSAGE(=[~message]=)= unconditionally writes the [~message]\ninto the test runner log file. Unlike __boost_test_checkpoint__ no\nfile and line number information is written into the log file. The\n[~message] is applied to an output stream with `operator<<` and can\ninclude other invocations of `operator<<`.\n\n[example_test_message]\n\n[endsect]\n\n[section =BOOST_TEST_PASSPOINT=]\n\n=BOOST_TEST_PASSPOINT()= is similar to __boost_test_checkpoint__, but \nonly registers a source file location with the test runner.\n\n[example_passpoint]\n \n[endsect]\n\n[endsect]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/ref-runner.qbk",
"content": "[/==============================================================================\n Copyright (C) 2013 Richard Thomson\n\n Distributed under the Boost Software License, Version 1.0. (See accompanying\n file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)\n===============================================================================/]\n\n[section:runner Test Runner]\n\n[include:test ref-runner-argument.qbk]\n\n[include:test ref-runner-output.qbk]\n\n[endsect]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/ref-test-case.qbk",
"content": "[/==============================================================================\n Copyright (C) 2013 Richard Thomson\n\n Distributed under the Boost Software License, Version 1.0. (See accompanying\n file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)\n===============================================================================/]\n\n[section:test_case Test Cases]\n\nA test case is a named body of code providing the three phases of a test:\nsetup, exercise and verify. A test case is most conveniently created using\none of the provided test case macros listed in the following table.\n\n[table Test Case Macros\n[[Macro] [Description]]\n[[=BOOST_AUTO_TEST_CASE(=[~name]=)=]\n [Creates test case [~name] and automatically registers it with the test\n runner.]]\n[[=BOOST_AUTO_TEST_CASE_EXPECTED_FAILURES(=[~name], [~count]=)=]\n [Informs the test runner that test case [~name] should result in\n [~count] failures.]]\n[[=BOOST_AUTO_TEST_CASE_TEMPLATE(=[~name], [~T], [~types]=)=]\n [Automatically registers a test case [~name] parameterized by the\n template argument [~T] over the collection of [~types].]]\n[[=BOOST_FIXTURE_TEST_CASE(=[~name], [~fixture]=)=]\n [Creates test case [~name] derived from the fixture [~fixture] and\n automatically registers it with the test runner.]]\n[[=BOOST_PARAM_TEST_CASE(=[~fn], [~begin], [~end]=)=]\n [Manually creates a parameterized test case using the supplied callable\n object [~fn] and parameter iterators [~begin] and [~end].]]\n[[=BOOST_PARAM_CLASS_TEST_CASE(=[~fn], [~instance], [~begin], [~end]=)=]\n [Manually creates a parameterized test case using the supplied callable\n object [~fn], class instance [~instance] and parameter iterators\n [~begin] and [~end].]]\n[[=BOOST_TEST_CASE(=[~fn]=)=]\n [Manually creates a test case using the supplied callable object [~fn].]]\n[[=BOOST_TEST_CASE_TEMPLATE(=[~name], [~types]=)=]\n [Manually creates a set of test cases from the template test case\n [~name] for each type in [~types].]]\n[[=BOOST_TEST_CASE_TEMPLATE_FUNCTION(=[~name], [~T]=)=]\n [Manually creates a template test case [~name] parameterized by the\n template argument [~T].]]\n]\n\n[section:boost_auto_test_case =BOOST_AUTO_TEST_CASE=]\n\n=BOOST_AUTO_TEST_CASE(=[~name]=)= creates a test case class, a test case\ninvocation function, a test case unique identifier, registers the invocation\nfunction as a test case and begins the definition of the test method on\nthe test class. The test case class [~name] is derived from\n=BOOST_AUTO_TEST_CASE_FIXTURE= and contains a single method named\n=test_method=. The test invocation function instantiates the test case\nclass and invokes the test case method. Test log checkpoints are made\nbefore the test case class is instantiated and bracketing the test\nmethod invocation. This provides diagnostic checkpoints should a runtime\nerror cause a test case to be aborted before any assertions are made.\n\n[heading Example Source Code]\n\n* Tutorials:\n * [link test.tutorials.hello_test Hello, Test!]\n* System under test:\n * [@boost:/libs/test/doc/src/tutorials/hello_test/sut/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/tutorials/hello_test/sut/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/tutorials/hello_test/test/test_hello.cpp test_hello.cpp]\n\n[endsect]\n\n[section:boost_auto_test_case_expected_failures =BOOST_AUTO_TEST_CASE_EXPECTED_FAILURES=]\n\n=BOOST_AUTO_TEST_CASE_EXPECTED_FAILURES(=[~name], [~n]=)= is used to\ndecorate a test case with an expected failure count of [~n]. It should\nappear immediately preceding the macro that defines the test case, such as\n__boost_auto_test_case__ or __boost_fixture_test_case__. It can be used\nfor test cases declared at file scope or within a test suite. This macro\nshould only be used in the most exceptional of circumstances. Unit tests\nare designed to provide a safety net of regression tests against our code.\nIf we allow tests to stay failing, we are less motivated to correct them.\n\nAs a temporary measure, we may wish to annotate certain tests as known\nfailures. The count [~n] is the number of expected failed assertions\nduring the execution of the test case. When using the [link\ntest.reference.assertion.levels =CHECK=] level assertions, the total\nfailure count can be larger than one since the test case continues executing\npast a failed assertion. When using =REQUIRE= level assertions, the total\nfailure count will only be one as execution of the test case terminates on\nthe first failed assertion.\n\nIf =CHECK= level assertions are used and the number of failures is less\nthan or equal to [~n], the test runner will return a status code of =0=.\nIf the number of failures is greater than [~n], the test runner will\nreturn a status code of =201=. If =REQUIRE= level assertions are used,\nthe number of expected failures can be at most one and the test runner\nwill return a status code of =200= when one failed assertion is found.\n\n[import examples/auto_test_case_expected_failures.cpp]\n[expected_failures]\n\n[note When using the compiler formatted test output, Visual Studio\ninterprets the failed assertion output as a detected error, it will fail\nthe Post-Build event mechanism recommended in [link\ntest.guide.test_case_design Test Case Design and Maintenance].]\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/examples/auto_test_case_expected_failures.cpp auto_test_case_expected_failures.cpp]\n\n[endsect]\n\n[section:boost_auto_test_case_template =BOOST_AUTO_TEST_CASE_TEMPLATE=]\n\n=BOOST_AUTO_TEST_CASE_TEMPLATE(=[~name], [~var], [~types]=)= declares a\ntest case [~name] parameterized by a single template argument [~var]\nthat is evaluated for each type in [~types]. This allows you to write a\ntest case that exercises an invariant across a collection of types. The\nmacro expands into one test case for each type in [~types], with the\ntemplate argument [~var] assigned to each type. The [~types] argument\nmust be a Boost.MPL type list and must be defined as a =typedef=.\n\n[import examples/auto_test_case_template.cpp]\n[auto_test_case_template]\n\n[heading Example Source Code]\n\n* Tests:\n * [@boost:/libs/test/doc/src/examples/auto_test_case_template.cpp auto_test_case_template.cpp]\n\n[endsect]\n\n[section:boost_fixture_test_case =BOOST_FIXTURE_TEST_CASE=]\n\n=BOOST_FIXTURE_TEST_CASE(=[~name], [~fixture]=)= defines a test case class\n[~name] that derives from [~fixture]. If the test case is declared within\na test suite that also has a test fixture, then to get the cumulative\neffect of both fixtures the test case fixture should derive from the test\nsuite's fixture. Otherwise, the test case fixture will replace the test\nsuite fixture for a test case defined with =BOOST_FIXTURE_TEST_CASE=.\n\n[heading Example Source Code]\n\n* Tutorials:\n * [link test.tutorials.testing_with_fixtures Testing With Fixtures]\n* System under test:\n * [@boost:/libs/test/doc/src/tutorials/testing_with_fixtures/sut/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/tutorials/testing_with_fixtures/sut/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/tutorials/testing_with_fixtures/test/test_hello.cpp test_hello.cpp]\n\n[endsect]\n\n[section:boost_global_fixture =BOOST_GLOBAL_FIXTURE=]\n\n=BOOST_GLOBAL_FIXTURE(=[~name]=)= declares a global fixture that is\nconstructed before executing any test cases and is destroyed after\nexecuting all test cases. If more than one global fixture is defined in\na single source file, the fixtures are constructed in the order they\nappear in the source file and destroyed in the reverse order. If global\nfixtures are defined in multiple source files, the order in which global\nfixtures are initialized between source files is implementation dependent.\n\nBecause global fixtures are not created and destroyed for each test case,\nthey represent shared state that prevents test cases from executing\nindependently from each other. For this reason, test case fixtures\ncreated with __boost_fixture_test_case__ and test suite fixtures created\nwith __boost_fixture_test_suite__ are preferred over global fixtures.\n\n[import examples/global_fixture.cpp][global_fixture]\n\n[heading Example Source Code]\n\n* Tests:\n * [@boost:/libs/test/doc/src/examples/another_global_fixture.cpp another_global_fixture.cpp]\n * [@boost:/libs/test/doc/src/examples/global_fixture.cpp global_fixture.cpp]\n\n[endsect]\n\n[section:boost_param_test_case =BOOST_PARAM_TEST_CASE=]\n\n=BOOST_PARAM_TEST_CASE(=[~fn], [~begin], [~end]=)= creates a series of\ntest cases that invoking the callable object [~fn] on the items in the\ncollection defined by [~begin] and [~end]. The test case returned by\n=BOOST_PARAM_TEST_CASE= must be added to a test suite in an initialization\nfunction for the tests to be executed. The iterators [~begin] and [~end]\nmust be valid at the time the test case executes and not just at the time\nthe test case is created.\n\n[import examples/param_test_case.cpp][param_test_case]\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/examples/param_test_case.cpp param_test_case.cpp]\n\n[endsect]\n\n[section:boost_param_class_test_case =BOOST_PARAM_CLASS_TEST_CASE=]\n\n=BOOST_PARAM_CLASS_TEST_CASE(=[~memfn], [~instance], [~begin], [~end]=)=\nworks similarly to __boost_param_test_case__. It creates a collection of\ntest cases that invoke the member function [~memfn] on the instance pointer\n[~instance]. The member function is passed an item obtained by iterating\nthe collection defined by the [~begin] and [~end] iterators. The [~instance]\npointer must be passed as a =boost::shared_ptr= to ensure the lifetime\nof the instance exceeds that of any test case using the instance.\nThe test case returned by =BOOST_PARAM_CLASS_TEST_CASE= must be added to\na test suite in an initialization function for the tests to be executed. \n\n[import examples/param_class_test_case.cpp][param_class_test_case]\n\n[note The single [~instance] is shared among all test cases and therefore\nshould not keep any shared state that may couple independent test cases.\nIn this example, the output string stream is created fresh inside each\ntest method and not shared between calls to the method.]\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/examples/param_class_test_case.cpp param_class_test_case.cpp]\n\n[endsect]\n\n[section:boost_test_case =BOOST_TEST_CASE=]\n\n=BOOST_TEST_CASE(=[~fn]=)= creates a new test case named \"fn\" that executes\nthe callable function [~fn]. The test case returned by =BOOST_TEST_CASE=\nmust be added to a test suite in an initialization function for the tests\nto be executed. \n\n[import examples/test_case.cpp][test_case]\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/examples/test_case.cpp test_case.cpp]\n\n[endsect]\n\n[section:boost_test_case_template =BOOST_TEST_CASE_TEMPLATE=]\n\n=BOOST_TEST_CASE_TEMPLATE(=[~name], [~types]=)= manually creates a set of\ntest cases from the template test case [~name] for each type in [~types].\nThe test case returned by =BOOST_TEST_CASE_TEMPLATE= must be added to a\ntest suite in an initialization function for the tests to be executed.\nThe test case function is defined with the\n__boost_test_case_template_function__ macro.\n\n[import examples/test_case_template.cpp][test_case_template]\n\n[heading Example Source Code]\n\n* Tests:\n * [@boost:/libs/test/doc/src/examples/test_case_template.cpp test_case_template.cpp]\n\n[endsect]\n\n[section:boost_test_case_template_function =BOOST_TEST_CASE_TEMPLATE_FUNCTION=]\n\n=BOOST_TEST_CASE_TEMPLATE_FUNCTION(=[~name], [~T]=)= defines a test\ncase function named [~name] that is parameterized by a type parameter\n[~T]. The defined functions are then available for registration as\nparameterized test cases with __boost_test_case_template__.\n\n[test_case_template_function]\n\n[heading Example Source Code]\n\n* Tests:\n * [@boost:/libs/test/doc/src/examples/test_case_template.cpp test_case_template.cpp]\n\n[endsect]\n\n[endsect]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/ref-test-case.qbk.bak",
"content": "[/==============================================================================\n Copyright (C) 2013 Richard Thomson\n\n Distributed under the Boost Software License, Version 1.0. (See accompanying\n file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)\n===============================================================================/]\n\n[section:test_case Test Cases]\n\nA test case is a named body of code providing the three phases of a test:\nsetup, exercise and verify. A test case is most conveniently created using\none of the provided test case macros listed in the following table.\n\n[table Test Case Macros\n[[Macro] [Description]]\n[[=BOOST_AUTO_TEST_CASE(=[~name]=)=]\n [Creates test case [~name] and automatically registers it with the test\n runner.]]\n[[=BOOST_AUTO_TEST_CASE_EXPECTED_FAILURES(=[~name], [~count]=)=]\n [Informs the test runner that test case [~name] should result in\n [~count] failures.]]\n[[=BOOST_AUTO_TEST_CASE_TEMPLATE(=[~name], [~T], [~types]=)=]\n [Automatically registers a test case [~name] parameterized by the\n template argument [~T] over the collection of [~types].]]\n[[=BOOST_FIXTURE_TEST_CASE(=[~name], [~fixture]=)=]\n [Creates test case [~name] derived from the fixture [~fixture] and\n automatically registers it with the test runner.]]\n[[=BOOST_PARAM_TEST_CASE(=[~fn], [~begin], [~end]=)=]\n [Manually creates a parameterized test case using the supplied callable\n object [~fn] and parameter iterators [~begin] and [~end].]]\n[[=BOOST_PARAM_CLASS_TEST_CASE(=[~fn], [~instance], [~begin], [~end]=)=]\n [Manually creates a parameterized test case using the supplied callable\n object [~fn], class instance [~instance] and parameter iterators\n [~begin] and [~end].]]\n[[=BOOST_TEST_CASE(=[~fn]=)=]\n [Manually creates a test case using the supplied callable object [~fn].]]\n[[=BOOST_TEST_CASE_TEMPLATE(=[~name], [~types]=)=]\n [Manually creates a set of test cases from the template test case\n [~name] for each type in [~types].]]\n[[=BOOST_TEST_CASE_TEMPLATE_FUNCTION(=[~name], [~T]=)=]\n [Manually creates a template test case [~name] parameterized by the\n template argument [~T].]]\n]\n\n[section:boost_auto_test_case =BOOST_AUTO_TEST_CASE=]\n\n=BOOST_AUTO_TEST_CASE(=[~name]=)= creates a test case class, a test case\ninvocation function, a test case unique identifier, registers the invocation\nfunction as a test case and begins the definition of the test method on\nthe test class. The test case class [~name] is derived from\n=BOOST_AUTO_TEST_CASE_FIXTURE= and contains a single method named\n=test_method=. The test invocation function instantiates the test case\nclass and invokes the test case method. Test log checkpoints are made\nbefore the test case class is instantiated and bracketing the test\nmethod invocation. This provides diagnostic checkpoints should a runtime\nerror cause a test case to be aborted before any assertions are made.\n\n[heading Example Source Code]\n\n* Tutorials:\n * [link test.tutorials.hello_test Hello, Test!]\n* System under test:\n * [@boost:/libs/test/doc/src/tutorials/hello_test/sut/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/tutorials/hello_test/sut/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/tutorials/hello_test/test/test_hello.cpp test_hello.cpp]\n\n[endsect]\n\n[section:boost_auto_test_case_expected_failures =BOOST_AUTO_TEST_CASE_EXPECTED_FAILURES=]\n\n=BOOST_AUTO_TEST_CASE_EXPECTED_FAILURES(=[~name], [~n]=)= is used to\ndecorate a test case with an expected failure count of [~n]. It should\nappear immediately preceding the macro that defines the test case, such as\n__boost_auto_test_case__ or __boost_fixture_test_case__. It can be used\nfor test cases declared at file scope or within a test suite. This macro\nshould only be used in the most exceptional of circumstances. Unit tests\nare designed to provide a safety net of regression tests against our code.\nIf we allow tests to stay failing, we are less motivated to correct them.\n\nAs a temporary measure, we may wish to annotate certain tests as known\nfailures. The count [~n] is the number of expected failed assertions\nduring the execution of the test case. When using the [link\ntest.reference.assertion.levels =CHECK=] level assertions, the total\nfailure count can be larger than one since the test case continues executing\npast a failed assertion. When using =REQUIRE= level assertions, the total\nfailure count will only be one as execution of the test case terminates on\nthe first failed assertion.\n\nIf =CHECK= level assertions are used and the number of failures is less\nthan or equal to [~n], the test runner will return a status code of =0=.\nIf the number of failures is greather than [~n], the test runner will\nreturn a status code of =201=. If =REQUIRE= level assertions are used,\nthe number of expected failures can be at most one and the test runner\nwill return a status code of =200= when one failed assertion is found.\n\n[import examples/auto_test_case_expected_failures.cpp]\n[expected_failures]\n\n[note When using the compiler formatted test output, Visual Studio\ninterprets the failed assertion output as a detected error, it will fail\nthe Post-Build event mechanism recommended in [link\ntest.guide.test_case_design Test Case Design and Maintenance].]\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/examples/auto_test_case_expected_failures.cpp auto_test_case_expected_failures.cpp]\n\n[endsect]\n\n[section:boost_auto_test_case_template =BOOST_AUTO_TEST_CASE_TEMPLATE=]\n\n=BOOST_AUTO_TEST_CASE_TEMPLATE(=[~name], [~var], [~types]=)= declares a\ntest case [~name] parameterized by a single template argument [~var]\nthat is evaluated for each type in [~types]. This allows you to write a\ntest case that exercises an invariant across a collection of types. The\nmacro expands into one test case for each type in [~types], with the\ntemplate argument [~var] assigned to each type. The [~types] argument\nmust be a Boost.MPL type list and must be defined as a =typedef=.\n\n[import examples/auto_test_case_template.cpp]\n[auto_test_case_template]\n\n[heading Example Source Code]\n\n* Tests:\n * [@boost:/libs/test/doc/src/examples/auto_test_case_template.cpp auto_test_case_template.cpp]\n\n[endsect]\n\n[section:boost_fixture_test_case =BOOST_FIXTURE_TEST_CASE=]\n\n=BOOST_FIXTURE_TEST_CASE(=[~name], [~fixture]=)= defines a test case class\n[~name] that derives from [~fixture]. If the test case is declared within\na test suite that also has a test fixture, then to get the cumulative\neffect of both fixtures the test case fixture should derive from the test\nsuite's fixture. Otherwise, the test case fixture will replace the test\nsuite fixture for a test case defined with =BOOST_FIXTURE_TEST_CASE=.\n\n[heading Example Source Code]\n\n* Tutorials:\n * [link test.tutorials.testing_with_fixtures Testing With Fixtures]\n* System under test:\n * [@boost:/libs/test/doc/src/tutorials/testing_with_fixtures/sut/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/tutorials/testing_with_fixtures/sut/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/tutorials/testing_with_fixtures/test/test_hello.cpp test_hello.cpp]\n\n[endsect]\n\n[section:boost_global_fixture =BOOST_GLOBAL_FIXTURE=]\n\n=BOOST_GLOBAL_FIXTURE(=[~name]=)= declares a global fixture that is\nconstructed before executing any test cases and is destroyed after\nexecuting all test cases. If more than one global fixture is defined in\na single source file, the fixtures are constructed in the order they\nappear in the source file and destroyed in the reverse order. If global\nfixtures are defined in multiple source files, the order in which global\nfixtures are initialized between source files is implementation dependent.\n\nBecause global fixtures are not created and destroyed for each test case,\nthey represent shared state that prevents test cases from executing\nindependently from each other. For this reason, test case fixtures\ncreated with __boost_fixture_test_case__ and test suite fixtures created\nwith __boost_fixture_test_suite__ are preferred over global fixtures.\n\n[import examples/global_fixture.cpp][global_fixture]\n\n[heading Example Source Code]\n\n* Tests:\n * [@boost:/libs/test/doc/src/examples/another_global_fixture.cpp another_global_fixture.cpp]\n * [@boost:/libs/test/doc/src/examples/global_fixture.cpp global_fixture.cpp]\n\n[endsect]\n\n[section:boost_param_test_case =BOOST_PARAM_TEST_CASE=]\n\n=BOOST_PARAM_TEST_CASE(=[~fn], [~begin], [~end]=)= creates a series of\ntest cases that invoking the callable object [~fn] on the items in the\ncollection defined by [~begin] and [~end]. The test case returned by\n=BOOST_PARAM_TEST_CASE= must be added to a test suite in an initialization\nfunction for the tests to be executed. The iterators [~begin] and [~end]\nmust be valid at the time the test case executes and not just at the time\nthe test case is created.\n\n[import examples/param_test_case.cpp][param_test_case]\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/examples/param_test_case.cpp param_test_case.cpp]\n\n[endsect]\n\n[section:boost_param_class_test_case =BOOST_PARAM_CLASS_TEST_CASE=]\n\n=BOOST_PARAM_CLASS_TEST_CASE(=[~memfn], [~instance], [~begin], [~end]=)=\nworks similarly to __boost_param_test_case__. It creates a collection of\ntest cases that invoke the member function [~memfn] on the instance pointer\n[~instance]. The member function is passed an item obtained by iterating\nthe collection defined by the [~begin] and [~end] iterators. The [~instance]\npointer must be passed as a =boost::shared_ptr= to ensure the lifetime\nof the instance exceeds that of any test case using the instance.\nThe test case returned by =BOOST_PARAM_CLASS_TEST_CASE= must be added to\na test suite in an initialization function for the tests to be executed. \n\n[import examples/param_class_test_case.cpp][param_class_test_case]\n\n[note The single [~instance] is shared among all test cases and therefore\nshould not keep any shared state that may couple independent test cases.\nIn this example, the output string stream is created fresh inside each\ntest method and not shared between calls to the method.]\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/examples/param_class_test_case.cpp param_class_test_case.cpp]\n\n[endsect]\n\n[section:boost_test_case =BOOST_TEST_CASE=]\n\n=BOOST_TEST_CASE(=[~fn]=)= creates a new test case named \"fn\" that executes\nthe callable function [~fn]. The test case returned by =BOOST_TEST_CASE=\nmust be added to a test suite in an initialization function for the tests\nto be executed. \n\n[import examples/test_case.cpp][test_case]\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/examples/test_case.cpp test_case.cpp]\n\n[endsect]\n\n[section:boost_test_case_template =BOOST_TEST_CASE_TEMPLATE=]\n\n=BOOST_TEST_CASE_TEMPLATE(=[~name], [~types]=)= manually creates a set of\ntest cases from the template test case [~name] for each type in [~types].\nThe test case returned by =BOOST_TEST_CASE_TEMPLATE= must be added to a\ntest suite in an initialization function for the tests to be executed.\nThe test case function is defined with the\n__boost_test_case_template_function__ macro.\n\n[import examples/test_case_template.cpp][test_case_template]\n\n[heading Example Source Code]\n\n* Tests:\n * [@boost:/libs/test/doc/src/examples/test_case_template.cpp test_case_template.cpp]\n\n[endsect]\n\n[section:boost_test_case_template_function =BOOST_TEST_CASE_TEMPLATE_FUNCTION=]\n\n=BOOST_TEST_CASE_TEMPLATE_FUNCTION(=[~name], [~T]=)= defines a test\ncase function named [~name] that is parameterized by a type parameter\n[~T]. The defined functions are then available for registration as\nparameterized test cases with __boost_test_case_template__.\n\n[test_case_template_function]\n\n[heading Example Source Code]\n\n* Tests:\n * [@boost:/libs/test/doc/src/examples/test_case_template.cpp test_case_template.cpp]\n\n[endsect]\n\n[endsect]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/ref-test-classes.qbk",
"content": "[/==============================================================================\n Copyright (C) 2013 Richard Thomson\n\n Distributed under the Boost Software License, Version 1.0. (See accompanying\n file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)\n===============================================================================/]\n\n[section:test_classes Test Classes]\n\nMost of the time you will not need to interact with the classes in __test__\nbecause the macro facilities for assertions, test cases and test suites\nhide all the details of the classes.\nIf you are adapting legacy test code to __test__ you may need to interact\nwith these classes in order to leverage existing test code without\nsignificant refactoring of the legacy test code.\n\nThe [link test.reference.test_classes.predicate_result =predicate_result=]\nclass is used to combine a boolean result from a predicate with a custom\nfailure message for reporting additional detail in the context of a failed\nassertion.\nThe [link test.reference.test_classes.test_unit =test_unit=],\n[link test.reference.test_classes.test_case =test_case=],\n[link test.reference.test_classes.test_suite =test_suite=] and\n[link test.reference.test_classes.master_test_suite_t =master_test_suite_t=]\nclasses provide the interface to test suites and their test cases for the\ntest runner.\nThe [link test.reference.test_classes.test_observer =test_observer=],\n[link test.reference.test_classes.unit_test_log_t =unit_test_log_t=]\nand [link test.reference.test_classes.unit_test_log_formatter =unit_test_log_formatter=]\nclasses provide low-level interaction with the test runner log.\n\n[section:predicate_result =predicate_result=]\n\nThe =predicate_result= class combines a boolean result from a predicate\nwith a detailed context message for a failed predicate evaluation. Usually\nthis class is only used in the internal implementation of the test framework,\nbut a user can define their own custom predicates that return a =predicate_result=\nto support detailed failure messages when an assertion fails.\n\n=predicate_result= is constructable and assignable from =bool=.\nThe =message()= method returns an output string stream that can be used\nto build up a context message.\n\n[import ../../../../boost/test/predicate_result.hpp]\n[predicate_result_decl]\n\nSee __boost_require_message__ for an example using =predicate_result=.\n\n[endsect]\n\n[section:test_unit =test_unit=]\n\nThe =test_unit= class forms the basis of the hierarchical tree of test\ncases.\nTest applications will usually create instances of =test_case=\nor =test_suite=, both of which derive from =test_unit=.\n\n[import ../../../../boost/test/unit_test_suite_impl.hpp][test_unit_decl]\n\n[endsect]\n\n[section:test_case =test_case=]\n\nThe =test_case= class represents a single test case.\nA test case must be added to a test suite reachable from the master test\nsuite in order for the test runner to run the test case.\n\n[test_case_decl]\n\n[endsect]\n\n[section:test_suite =test_suite=]\n\nThe =test_suite= class represents a group of test cases and suites in\nthe test tree hierarchy.\n\n[test_suite_decl]\n\n[endsect]\n\n[section:master_test_suite_t =master_test_suite_t=]\n\nThe master test suite of type =master_test_suite_t= is the starting point\nfor the test runner.\n\n[master_test_suite_t_decl]\n\nYou can obtain a reference to the master test suite with the\n=master_test_suite()= function:\n\n[import ../../../../boost/test/framework.hpp][master_test_suite_decl]\n\n[endsect]\n\n[section:test_observer =test_observer=]\n\nThe =test_observer= class encapsulates observers of test execution. It\nprovides a simple /null/ style observer behavior.\n\n[import ../../../../boost/test/test_observer.hpp][test_observer_decl]\n\n[endsect]\n\n[section:unit_test_log_t =unit_test_log_t=]\n\nThe =unit_test_log_t= class encapsulates the unit test log. You obtain\na reference to the single global unit test log instance with the\n=unit_test_log= member.\n\n[import ../../../../boost/test/unit_test_log.hpp][unit_test_log_t_decl]\n\n[endsect]\n\n[section:unit_test_log_formatter =unit_test_log_formatter=]\n\nThe =unit_test_log_formatter= class encapsulates formatting of log events\nfor an output stream.\n\n[import ../../../../boost/test/unit_test_log_formatter.hpp][unit_test_log_formatter_decl]\n\n[endsect]\n\n[section:init_unit_test_func =init_unit_test_func=]\n\nThe =init_unit_test_func= function typedef identifies the signature of\nthe user supplied initialization function. The initialization function\ncan be used to add custom test cases and test suites to the test tree.\n\n[init_unit_test_func_decl]\n\n[endsect]\n\n[section:unit_test_main =unit_test_main=]\n\nThe =unit_test_main= function provides an implementation of =main= that\ncan be used by a test executable compiled with __boost_test_no_main__.\n\n[import ../../../../boost/test/unit_test.hpp][unit_test_main_decl]\n\n=unit_test_main= initializes the test framework, traverses the test\ntree and reports the result as a the return value of the function.\nUnexpected exceptions and system errors (signals, etc.) are caught and\nmapped to appropriate return values by the function.\n\n[endsect]\n\n[endsect]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/ref-test-suite.qbk",
"content": "[/==============================================================================\n Copyright (C) 2013 Richard Thomson\n\n Distributed under the Boost Software License, Version 1.0. (See accompanying\n file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)\n===============================================================================/]\n\n[section:test_suite Test Suites]\n\nA test suite is an ordered collection of test cases and other test suites.\nThe test cases in a suite are executed in the order in which they are\nadded to the suite. When test cases are automatically registered, they\nare added to the test suite in the order of their definition in the source\nfile.\n\n[section:boost_auto_test_suite =BOOST_AUTO_TEST_SUITE=]\n\nThe =BOOST_AUTO_TEST_SUITE(=[~name]=)= macro defines an automatically\nregistered test suite named [~name] and opens a namespace named [~name].\n\nA test suite can be nested\nwithin another test suite. Each test suite begun with\n=BOOST_AUTO_TEST_SUITE= must be ended with [link\ntest.reference.test_suite.boost_auto_test_suite_end =BOOST_AUTO_TEST_SUITE_END=]\nThe new test suite is registered within its enclosing test suite, or the\nmaster test suite if there is no enclosing test suite.\n\n[heading Example Source Code]\n\n* Tutorials:\n * [link test.tutorials.running_selected_tests Running Selected Tests]\n* System under test:\n * [@boost:/libs/test/doc/src/tutorials/running_selected_tests/sut/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/tutorials/running_selected_tests/sut/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/tutorials/running_selected_tests/test/test_hello.cpp test_hello.cpp]\n\n[endsect]\n\n[section:boost_auto_test_suite_end =BOOST_AUTO_TEST_SUITE_END=]\n\nThe =BOOST_AUTO_TEST_SUITE_END()= macro ends the test suite most recently\ndefined with [link test.reference.test_suite.boost_auto_test_suite =BOOST_AUTO_TEST_SUITE=]\nor [link test.reference.test_suite.boost_fixture_test_suite =BOOST_FIXTURE_TEST_SUITE=].\nThe corresponding namespace created when the test suite was defined is\nclosed by =BOOST_AUTO_TEST_SUITE_END=.\n\n[heading Example Source Code]\n\n* Tutorials:\n * [link test.tutorials.running_selected_tests Running Selected Tests]\n* System under test:\n * [@boost:/libs/test/doc/src/tutorials/running_selected_tests/sut/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/tutorials/running_selected_tests/sut/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/tutorials/running_selected_tests/test/test_hello.cpp test_hello.cpp]\n\n[endsect]\n\n[section:boost_fixture_test_suite =BOOST_FIXTURE_TEST_SUITE=]\n\nThe =BOOST_FIXTURE_TEST_SUITE(=[~suite], [~fixture]=)= macro begins the\ntest suite named [~suite] and uses [~fixture] as a test fixture to be\nused as the base class of all test case classes created in the suite with\n=BOOST_AUTO_TEST_CASE=.\n\n[heading Example Source Code]\n\n* Tutorials:\n * [link test.tutorials.running_selected_tests Running Selected Tests]\n* System under test:\n * [@boost:/libs/test/doc/src/tutorials/running_selected_tests/sut/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/tutorials/running_selected_tests/sut/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/tutorials/running_selected_tests/test/test_hello.cpp test_hello.cpp]\n\n[endsect]\n\n[section:boost_test_module =BOOST_TEST_MODULE=]\n\nThe =BOOST_TEST_MODULE= macro is used to define the name of the master\ntest suite. If =BOOST_TEST_MODULE= is defined, it should be defined in\nexactly one source file. It can be defined to a list of preprocessor\ntokens or a string literal. If a string literal is used, surrounding\nquotation marks (=\"=), will not appear in the name of the master test\nsuite.\n\n[example_test_module]\n\n[heading Example Source Code]\n* Tests:\n * [@boost:/libs/test/doc/src/examples/assertions.cpp assertions.cpp]\n\n[endsect]\n\n[section:boost_test_suite =BOOST_TEST_SUITE=]\n\nThe =BOOST_TEST_SUITE(=[~name]=)= macro is used to create a new test suite\nnamed [~name]. The new suite must be added to the master test suite in\norder for any test cases in the suite to be executed.\n\n[register_test_suite]\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/examples/manual_registration.cpp manual_registration.cpp]\n\n[endsect]\n\n[endsect]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/reference.qbk",
"content": "[/==============================================================================\n Copyright (C) 2013 Richard Thomson\n\n Distributed under the Boost Software License, Version 1.0. (See accompanying\n file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)\n===============================================================================/]\n\n[section:reference Reference]\n\n[import examples/assertions.cpp]\n[import examples/assertion_failures.cpp]\n\n[include:test ref-compilation.qbk]\n[include:test ref-test-case.qbk]\n[include:test ref-test-suite.qbk]\n[include:test ref-test-classes.qbk]\n[include:test ref-assertion.qbk]\n[include:test ref-runner.qbk]\n\n[endsect]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/system_under_test/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nalias system_under_test :\n hello//hello\n scanner//scanner\n ;\n\nbuild-project hello ;\nbuild-project scanner ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/system_under_test/hello/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nlib hello : hello.cpp : static ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/system_under_test/hello/hello.cpp",
"content": "#include \"hello.hpp\"\n\nvoid hello_world(std::ostream& stream)\n{\n if (stream.bad())\n {\n throw std::runtime_error(\"bad stream\");\n }\n stream << \"Hello, world!\\n\";\n}\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/system_under_test/hello/hello.hpp",
"content": "//[ hello_test_sut_hpp\n#if !defined(HELLO_HPP)\n#define HELLO_HPP\n\n#include \n\nextern void hello_world(std::ostream& stream);\n\n#endif\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/system_under_test/scanner/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nlib scanner : scanner.cpp : static ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/system_under_test/scanner/directory_scanner.hpp",
"content": "#if !defined(DIRECTORY_SCANNER_H)\n#define DIRECTORY_SCANNER_H\n\n#include \n\n//[directory_scanner\nclass directory_scanner\n{\npublic:\n virtual ~directory_scanner() {}\n\n virtual void begin(std::string const &directory) = 0;\n\n virtual bool has_next() const = 0;\n\n virtual std::string next() const = 0;\n};\n//]\n\n#endif\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/system_under_test/scanner/filesystem_directory_scanner.hpp",
"content": "#if !defined(FILESYSTEM_DIRECTORY_SCANNER_H)\n#define FILESYSTEM_DIRECTORY_SCANNER_H\n\n#include \"directory_scanner.hpp\"\n#include \n\n//[filesystem_directory_scanner\nclass filesystem_directory_scanner : public directory_scanner\n{\npublic:\n filesystem_directory_scanner() {}\n virtual ~filesystem_directory_scanner() {}\n\n virtual void begin(std::string const &directory)\n {\n current = boost::filesystem::directory_iterator(directory);\n }\n\n virtual bool has_next() const\n {\n return current != end;\n }\n\n virtual std::string next() const\n {\n if (has_next())\n {\n std::string const result = (*current).path().filename().string();\n do\n {\n ++current;\n }\n while (has_next() && !boost::filesystem::is_regular_file((*current).path()));\n return result;\n }\n throw std::runtime_error(\"no next path\");\n }\n\nprivate:\n mutable boost::filesystem::directory_iterator current;\n boost::filesystem::directory_iterator end;\n};\n//]\n\n#endif\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/system_under_test/scanner/scanner.cpp",
"content": "#include \"scanner.hpp\"\r\n#include \"filesystem_directory_scanner.hpp\"\r\n\r\n//[text_files_dependency_impl\r\nextern std::vector\r\ntext_files(std::string const &directory,\r\n directory_scanner &scanner)\r\n{\r\n std::vector files;\r\n scanner.begin(directory);\r\n while (scanner.has_next())\r\n {\r\n std::string file(scanner.next());\r\n if (file.length() >= 4 &&\r\n file.substr(file.length() - 4) == \".txt\")\r\n {\r\n files.push_back(file);\r\n }\r\n }\r\n return files;\r\n}\r\n//]\r\n\r\n//[text_files_impl\r\nextern std::vector\r\ntext_files(std::string const& directory)\r\n{\r\n filesystem_directory_scanner scanner;\r\n return text_files(directory, scanner);\r\n}\r\n//]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/system_under_test/scanner/scanner.hpp",
"content": "#if !defined(SCANNER_HPP)\n#define SCANNER_HPP\n\n#include \n#include \n\n//[text_files_decl\nextern std::vector text_files(std::string const& directory);\n//]\n\n//[text_files_dependency_decl\nclass directory_scanner;\n\nextern std::vector text_files(\n std::string const& directory,\n directory_scanner& scanner);\n//]\n\n#endif\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/test.qbk",
"content": "[/==============================================================================\n Copyright (C) 2013 Richard Thomson\n\n Distributed under the Boost Software License, Version 1.0. (See accompanying\n file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)\n===============================================================================/]\n\n[library Boost.Test\n [quickbook 1.5]\n [authors [Thomson, Richard]]\n [copyright 2013 Richard Thomson]\n [/ purpose Unit Testing Library]\n [license\n Distributed under the Boost Software License, Version 1.0.\n (See accompanying file LICENSE_1_0.txt or copy at\n [@http://www.boost.org/LICENSE_1_0.txt])\n ]\n [id test]\n [source-mode c++]\n [dirname test]\n]\n\n[/ April 23, 2013 ]\n\n[/ TODO: Stuff that needs to be fixed by these docs:\n\nhttps://svn.boost.org/trac/boost/ticket/2600\ndocument method test_unit::depends_on \n\nhttps://svn.boost.org/trac/boost/ticket/7136\nCorrect documentation for BOOST__CLOSE_FRACTION is not reflected into released documents\n\n]\n\n[/ Some symbols ]\n\n[def __test__ Boost.Test]\n\n[/ Some web links ]\n\n[def __test_driven_development__ [@http://en.wikipedia.org/wiki/Test-driven_development test-driven development]]\n[def __xunit_patterns__ [@http://xunitpatterns.com xUnit Test Patterns]]\n\n[/ Internal links to the reference ]\n\n[def __boost_fail__ [link test.reference.assertion.boost_fail =BOOST_FAIL=]]\n[def __boost_require_equal__ [link test.reference.assertion.boost_level_equal =BOOST_REQUIRE_EQUAL=]]\n[def __boost_require_exception__ [link test.reference.assertion.boost_level_exception =BOOST_REQUIRE_EXCEPTION=]]\n[def __boost_require_message__ [link test.reference.assertion.boost_level_message =BOOST_REQUIRE_MESSAGE=]]\n[def __boost_require_no_throw__ [link test.reference.assertion.boost_level_no_throw =BOOST_REQUIRE_NO_THROW=]]\n[def __boost_require_throw__ [link test.reference.assertion.boost_level_throw =BOOST_REQUIRE_THROW=]]\n\n[def __boost_test_alternative_init_api__\n [link test.reference.compilation.boost_test_alternative_init_api =BOOST_TEST_ALTERNATIVE_INIT_API=]]\n[def __boost_test_dyn_link__ [link test.reference.compilation.boost_test_dyn_link =BOOST_TEST_DYN_LINK=]]\n[def __boost_test_main__ [link test.reference.compilation.boost_test_main =BOOST_TEST_MAIN=]]\n[def __boost_test_no_lib__ [link test.reference.compilation.boost_test_no_lib =BOOST_TEST_NO_LIB=]]\n[def __boost_test_no_main__ [link test.reference.compilation.boost_test_no_main =BOOST_TEST_NO_MAIN=]]\n\n[def __auto_start_dbg__ [link test.reference.runner.argument.auto_start_dbg =--auto_start_dbg=]]\n[def __log_format__ [link test.reference.runner.argument.log_format =--log_format=]]\n[def __log_level__ [link test.reference.runner.argument.log_level =--log_level=]]\n[def __log_sink__ [link test.reference.runner.argument.log_sink =--log_sink=]]\n[def __output_format__ [link test.reference.runner.argument.output_format =--output_format=]]\n[def __report_format__ [link test.reference.runner.argument.report_format =--report_format=]]\n[def __report_level__ [link test.reference.runner.argument.report_level =--report_level=]]\n[def __report_sink__ [link test.reference.runner.argument.report_sink =--report_sink=]]\n[def __run_test__ [link test.reference.runner.argument.run_test =--run_test=]]\n[def __boost_test_checkpoint__ [link test.reference.runner.output.boost_test_checkpoint =BOOST_TEST_CHECKPOINT=]]\n[def __boost_test_message__ [link test.reference.runner.output.boost_test_message =BOOST_TEST_MESSAGE=]]\n\n[def __boost_auto_test_case__ [link test.reference.test_case.boost_auto_test_case =BOOST_AUTO_TEST_CASE=]]\n[def __boost_fixture_test_case__ [link test.reference.test_case.boost_fixture_test_case =BOOST_FIXTURE_TEST_CASE=]]\n[def __boost_param_test_case__ [link test.reference.test_case.boost_param_test_case =BOOST_PARAM_TEST_CASE=]]\n[def __boost_test_case__ [link test.reference.test_case.boost_test_case =BOOST_TEST_CASE=]]\n[def __boost_test_case_template__ [link test.reference.test_case.boost_test_case_template =BOOST_TEST_CASE_TEMPLATE=]]\n[def __boost_test_case_template_function__ [link test.reference.test_case.boost_test_case_template_function =BOOST_TEST_CASE_TEMPLATE_FUNCTION=]]\n\n[def __boost_auto_test_suite__ [link test.reference.test_suite.boost_auto_test_suite =BOOST_AUTO_TEST_SUITE=]]\n[def __boost_fixture_test_suite__ [link test.reference.test_suite.boost_fixture_test_suite =BOOST_FIXTURE_TEST_SUITE=]]\n[def __boost_test_suite__ [link test.reference.test_suite.boost_test_suite =BOOST_TEST_SUITE=]]\n\n[def __predicate_result__ [link test.reference.test_classes.predicate_result =predicate_result=]]\n[def __unit_test_main__ [link test.reference.test_classes.unit_test_main =unit_test_main=]]\n\n[/ Some images ]\n\n[def __note__ [$./images/note.png]]\n[def __tip__ [$./images/tip.png]]\n[def __important__ [$./images/important.png]]\n[def __caution__ [$./images/caution.png]]\n[def __danger__ [$./images/alert.png]]\n\nThis is the documentation for __test__, a library designed to support\nautomated testing of software generally and unit testing specifically.\n\n[/----------------------------------------------------------------------]\n[section Motivation]\n\nAutomated tests are an important part of verifying software. At the\ndeveloper level, automated tests provide confidence that changes made to\nthe software do not result in new defects. At the customer level,\nautomated tests provide confidence that new features meet expectations\nand existing features continue to function unchanged.\n\n__test__ is a library that supports the automated testing of software,\nprimarily aimed at satisfying the needs of the developer.\n\n[endsect]\n\n[/----------------------------------------------------------------------]\n[section How To Read This Documentation]\n\nThis documentation provides material for both new users and advanced\nusers. If you are completely new to automated testing, you may wish\nto read Wikipedia's article on __test_driven_development__ and consult the\nonline book __xunit_patterns__. The amount of information available on\nautomated testing has exploded in the past decade and these are only\nsome suggested starting points and not intended to be an exhaustive\nlist.\n\nTo get started quickly writing your first test, read the\n[link test.tutorials tutorial] sections. For advice on designing and\nmaintaining your tests, read the section on\n[link test.guide.test_case_design test case design]. For advanced uses of the\nlibrary, consult the [link test.reference reference].\n\n[endsect]\n\n[include:test tutorials.qbk]\n[include:test user-guide.qbk]\n[include:test reference.qbk]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nalias tutorials :\n hello_test//tutorial_hello_test\n running_selected_tests\n testing_with_exceptions\n testing_with_fixtures ;\n\nbuild-project hello_test ;\nbuild-project running_selected_tests ;\nbuild-project testing_with_exceptions ;\nbuild-project testing_with_fixtures ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/1/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nalias tutorial_hello_test.1 : hello.1 hello_test.1 ;\n\nlib hello.1 : sut/hello.cpp : static ;\nrun-fail test/test_hello.cpp hello.1 : : : sut : hello_test.1 ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/1/hello_test~1.output",
"content": "[pre\r\nRunning 1 test case...\r\nsrc/tutorials/hello_test/1/test/test_hello.cpp(13): fatal error in \"hello_world_inserts_text\": critical check \"Hello, world!\\\\n\" == dest.str() failed [Hello, world!\r\n != \\]\r\n\r\n*** 1 failure detected in test suite \"Master Test Suite\"\r\n \r\nEXIT STATUS: 201 \r\n]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/1/sut/hello.cpp",
"content": "//[ hello_test_sut_cpp1\n#include \"hello.hpp\"\n\nvoid hello_world(std::ostream& stream)\n{\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/1/sut/hello.hpp",
"content": "//[ hello_test_sut_hpp1\n#if !defined(HELLO_HPP)\n#define HELLO_HPP\n\n#include \n\nextern void hello_world(std::ostream& stream);\n\n#endif\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/1/test/test_hello.cpp",
"content": "//[ hello_test_test_cpp1\n#define BOOST_TEST_MAIN\n#include \n#include \"hello.hpp\"\n#include \n\nBOOST_AUTO_TEST_CASE(hello_world_inserts_text)\n{\n std::ostringstream dest;\n\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/2/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nalias tutorial_hello_test.2 : hello.2 hello_test.2 ;\n\nlib hello.2 : sut/hello.cpp : static ;\nrun-fail test/test_hello.cpp hello.2 : : : sut : hello_test.2 ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/2/hello_test~2.output",
"content": "[pre\r\nRunning 1 test case...\r\nsrc/tutorials/hello_test/2/test/test_hello.cpp(13): fatal error in \"hello_world_inserts_text\": critical check \"Hello, world!\\\\n\" == dest.str() failed [Hello, world!\r\n != Hello, world!\\]\r\n\r\n*** 1 failure detected in test suite \"Master Test Suite\"\r\n \r\nEXIT STATUS: 201 \r\n]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/2/sut/hello.cpp",
"content": "//[ hello_test_sut_cpp2\n#include \"hello.hpp\"\n\nvoid hello_world(std::ostream& stream)\n{\n stream << \"Hello, world!\";\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/2/sut/hello.hpp",
"content": "//[ hello_test_sut_hpp2\n#if !defined(HELLO_HPP)\n#define HELLO_HPP\n\n#include \n\nextern void hello_world(std::ostream& stream);\n\n#endif\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/2/test/test_hello.cpp",
"content": "//[ hello_test_test_cpp2\n#define BOOST_TEST_MAIN\n#include \n#include \"hello.hpp\"\n#include \n\nBOOST_AUTO_TEST_CASE(hello_world_inserts_text)\n{\n std::ostringstream dest;\n\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/3/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nalias tutorial_hello_test.3 : hello.3 hello_test.3 ;\n\nlib hello.3 : sut/hello.cpp : static ;\nrun test/test_hello.cpp hello.3 : : : sut : hello_test.3 ;\n\u001a"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/3/hello_test~3.output",
"content": "[pre\r\nRunning 1 test case...\r\n\r\n*** No errors detected\r\n \r\nEXIT STATUS: 0 \r\n]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/3/sut/hello.cpp",
"content": "//[ hello_test_sut_cpp3\n#include \"hello.hpp\"\n\nvoid hello_world(std::ostream& stream)\n{\n stream << \"Hello, world!\" << std::endl;\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/3/sut/hello.hpp",
"content": "//[ hello_test_sut_hpp3\n#if !defined(HELLO_HPP)\n#define HELLO_HPP\n\n#include \n\nextern void hello_world(std::ostream& stream);\n\n#endif\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/3/test/test_hello.cpp",
"content": "//[ hello_test_test_cpp2\n#define BOOST_TEST_MAIN\n#include \n#include \"hello.hpp\"\n#include \n\nBOOST_AUTO_TEST_CASE(hello_world_inserts_text)\n{\n std::ostringstream dest;\n\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nalias tutorial_hello_test :\n 1//tutorial_hello_test.1\n 2//tutorial_hello_test.2\n 3//tutorial_hello_test.3\n hello.tutorial_hello_test\n hello_test\n ;\n\nbuild-project 1 ;\nbuild-project 2 ;\nbuild-project 3 ;\n\nlib hello.tutorial_hello_test : sut/hello.cpp : static ;\nrun test/test_hello.cpp hello.tutorial_hello_test : : : sut : hello_test ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/hello_test.output",
"content": "[pre\r\nRunning 1 test case...\r\n\r\n*** No errors detected\r\n \r\nEXIT STATUS: 0 \r\n]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/sut/hello.cpp",
"content": "//[ hello_test_sut_cpp\n#include \"hello.hpp\"\n\nvoid hello_world(std::ostream& stream)\n{\n stream << \"Hello, world!\\n\";\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/sut/hello.hpp",
"content": "//[ hello_test_sut_hpp\n#if !defined(HELLO_HPP)\n#define HELLO_HPP\n\n#include \n\nextern void hello_world(std::ostream& stream);\n\n#endif\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/hello_test/test/test_hello.cpp",
"content": "//[ hello_test_test_cpp\n#define BOOST_TEST_MAIN\n#include \n#include \"hello.hpp\"\n#include \n\nBOOST_AUTO_TEST_CASE(hello_world_inserts_text)\n{\n std::ostringstream dest;\n\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/1/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nalias running_selected_tests.1 :\n hello.running_selected_tests.1\n test_hello.running_selected_tests.1\n ;\n\nlib hello.running_selected_tests.1 : sut/hello.cpp : static ;\nrun test/test_hello.cpp hello.running_selected_tests.1\n : --run_test=hello_world_inserts_text,hello_world_stream_with_badbit_throws_runtime_error\n : : sut : test_hello.running_selected_tests.1 ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/1/report_level_detailed.output",
"content": "[pre\r\n> test_hello --report_level=detailed\r\nRunning 2 test cases...\r\n\r\nTest suite \"Master Test Suite\" passed with:\r\n 2 assertions out of 2 passed\r\n 2 test cases out of 2 passed\r\n\r\n Test case \"hello_world_inserts_text\" passed with:\r\n 1 assertion out of 1 passed\r\n\r\n Test case \"hello_world_stream_with_badbit_throws_runtime_error\" passed with:\r\n 1 assertion out of 1 passed\r\n\r\n]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/1/sut/hello.cpp",
"content": "#include \"hello.hpp\"\n\nvoid hello_world(std::ostream& stream)\n{\n if (stream.bad())\n {\n throw std::runtime_error(\"bad stream\");\n }\n stream << \"Hello, world!\\n\";\n}\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/1/sut/hello.hpp",
"content": "#if !defined(HELLO_HPP)\n#define HELLO_HPP\n\n#include \n\nextern void hello_world(std::ostream& stream);\n\n#endif\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/1/test/test_hello.cpp",
"content": "#define BOOST_TEST_MAIN\n#include \n#include \"hello.hpp\"\n#include \n#include \n\n//[running_selected_tests_test_cpp_1\nstruct hello_world_fixture\n{\n std::ostringstream dest;\n};\n\n#define HELLO_WORLD_TEST_CASE(name_) \\\n BOOST_FIXTURE_TEST_CASE(hello_world_##name_, hello_world_fixture)\n\nHELLO_WORLD_TEST_CASE(inserts_text)\n{\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n\nHELLO_WORLD_TEST_CASE(stream_with_badbit_throws_runtime_error)\n{\n dest.clear(std::ios_base::badbit);\n\n BOOST_REQUIRE_THROW(hello_world(dest), std::runtime_error);\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/1/test_hello~running_selected_tests~1.output",
"content": "[pre\r\n> test_hello --run_test=hello_world_inserts_text,hello_world_stream_with_badbit_throws_runtime_error\r\nRunning 2 test cases...\r\n\r\n*** No errors detected\r\n \r\nEXIT STATUS: 0 \r\n]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/2/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nalias running_selected_tests.2 :\n hello.running_selected_tests.2\n test_hello.running_selected_tests.2\n ;\n\nlib hello.running_selected_tests.2 : sut/hello.cpp : static ;\nrun test/test_hello.cpp hello.running_selected_tests.2\n : --run_test=test_hello\n : : sut : test_hello.running_selected_tests.2 ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/2/report_level_detailed.output",
"content": "[pre\r\n> test_hello --report_level=detailed\r\nRunning 2 test cases...\r\n\r\nTest suite \"Master Test Suite\" passed with:\r\n 2 assertions out of 2 passed\r\n 2 test cases out of 2 passed\r\n\r\n Test suite \"test_hello\" passed with:\r\n 2 assertions out of 2 passed\r\n 2 test cases out of 2 passed\r\n\r\n Test case \"hello_world_inserts_text\" passed with:\r\n 1 assertion out of 1 passed\r\n\r\n Test case \"hello_world_stream_with_badbit_throws_runtime_error\" passed with:\r\n 1 assertion out of 1 passed\r\n\r\n]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/2/run_test_hello_inserts_text.output",
"content": "[pre\r\n> test_hello --run_test=test_hello/hello_world_inserts_text\r\nRunning 1 test case...\r\n\r\n*** No errors detected\r\n]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/2/run_test_hello_star_inserts_text.output",
"content": "[pre\r\n> test_hello --run_test=hello_world/*inserts_text\r\nRunning 1 test case...\r\n\r\n*** No errors detected\r\n]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/2/sut/hello.cpp",
"content": "#include \"hello.hpp\"\n\nvoid hello_world(std::ostream& stream)\n{\n if (stream.bad())\n {\n throw std::runtime_error(\"bad stream\");\n }\n stream << \"Hello, world!\\n\";\n}\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/2/sut/hello.hpp",
"content": "#if !defined(HELLO_HPP)\n#define HELLO_HPP\n\n#include \n\nextern void hello_world(std::ostream& stream);\n\n#endif\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/2/test/test_hello.cpp",
"content": "#define BOOST_TEST_MAIN\n#include \n#include \"hello.hpp\"\n#include \n#include \n\n//[running_selected_tests_test_cpp_2\nstruct hello_world_fixture\n{\n std::ostringstream dest;\n};\n\nBOOST_AUTO_TEST_SUITE(test_hello);\n\n#define HELLO_WORLD_TEST_CASE(name_) \\\n BOOST_FIXTURE_TEST_CASE(hello_world_##name_, hello_world_fixture)\n\nHELLO_WORLD_TEST_CASE(inserts_text)\n{\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n\nHELLO_WORLD_TEST_CASE(stream_with_badbit_throws_runtime_error)\n{\n dest.clear(std::ios_base::badbit);\n\n BOOST_REQUIRE_THROW(hello_world(dest), std::runtime_error);\n}\n\nBOOST_AUTO_TEST_SUITE_END();\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/2/test_hello~running_selected_tests~2.output",
"content": "[pre\r\n> test_hello --run_test=test_hello\r\nRunning 2 test cases...\r\n\r\n*** No errors detected\r\n \r\nEXIT STATUS: 0 \r\n]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nalias running_selected_tests :\n 1//running_selected_tests.1\n 2//running_selected_tests.2\n ;\n\nbuild-project 1 ;\nbuild-project 2 ;\n\nlib hello.running_selected_tests : sut/hello.cpp : static ;\nrun test/test_hello.cpp hello.running_selected_tests : : : sut : test_hello ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/report_level_detailed.output",
"content": "[pre\r\n> test_hello.exe --report_level=detailed\r\nRunning 2 test cases...\r\n\r\nTest suite \"Master Test Suite\" passed with:\r\n 2 assertions out of 2 passed\r\n 2 test cases out of 2 passed\r\n\r\n Test suite \"test_hello\" passed with:\r\n 2 assertions out of 2 passed\r\n 2 test cases out of 2 passed\r\n\r\n Test case \"inserts_text\" passed with:\r\n 1 assertion out of 1 passed\r\n\r\n Test case \"stream_with_badbit_throws_runtime_error\" passed with:\r\n 1 assertion out of 1 passed\r\n\r\n]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/sut/hello.cpp",
"content": "#include \"hello.hpp\"\n\nvoid hello_world(std::ostream& stream)\n{\n if (stream.bad())\n {\n throw std::runtime_error(\"bad stream\");\n }\n stream << \"Hello, world!\\n\";\n}\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/sut/hello.hpp",
"content": "#if !defined(HELLO_HPP)\n#define HELLO_HPP\n\n#include \n\nextern void hello_world(std::ostream& stream);\n\n#endif\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/running_selected_tests/test/test_hello.cpp",
"content": "//[ running_selected_tests_test_cpp\n#define BOOST_TEST_MAIN\n#include \n#include \"hello.hpp\"\n#include \n#include \n\nstruct hello_world_fixture\n{\n std::ostringstream dest;\n};\n\nBOOST_FIXTURE_TEST_SUITE(test_hello, hello_world_fixture);\n\nBOOST_AUTO_TEST_CASE(inserts_text)\n{\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n\nBOOST_AUTO_TEST_CASE(stream_with_badbit_throws_runtime_error)\n{\n dest.clear(std::ios_base::badbit);\n\n BOOST_REQUIRE_THROW(hello_world(dest), std::runtime_error);\n}\n\nBOOST_AUTO_TEST_SUITE_END();\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_exceptions/1/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nalias testing_with_exceptions.1 :\n hello.testing_with_exceptions.1\n test_hello.testing_with_exceptions.1\n ;\n\nlib hello.testing_with_exceptions.1 : sut/hello.cpp : static ;\nrun-fail test/test_hello.cpp hello.testing_with_exceptions.1 : : : sut : test_hello.testing_with_exceptions.1 ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_exceptions/1/sut/hello.cpp",
"content": "//[ testing_with_exceptions_sut_cpp_1\n#include \"hello.hpp\"\n\nvoid hello_world(std::ostream& stream)\n{\n stream << \"Hello, world!\\n\";\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_exceptions/1/sut/hello.hpp",
"content": "//[ testing_with_exceptions_sut_hpp_1\n#if !defined(HELLO_HPP)\n#define HELLO_HPP\n\n#include \n\nextern void hello_world(std::ostream& stream);\n\n#endif\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_exceptions/1/test/test_hello.cpp",
"content": "#define BOOST_TEST_MAIN\n#include \n#include \"hello.hpp\"\n#include \n#include \n\nBOOST_AUTO_TEST_CASE(hello_world_inserts_text)\n{\n std::ostringstream dest;\n\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n\n//[ hello_world_stream_with_badbit_throws_runtime_error_1\nBOOST_AUTO_TEST_CASE(hello_world_stream_with_badbit_throws_runtime_error)\n{\n std::ostringstream dest;\n dest.clear(std::ios_base::badbit);\n\n hello_world(dest);\n\n BOOST_FAIL(\"std::runtime_error not thrown\");\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_exceptions/1/test_hello~testing_with_exceptions~1.output",
"content": "[pre\r\nRunning 2 test cases...\r\nsrc/tutorials/testing_with_exceptions/1/test/test_hello.cpp(24): fatal error in \"hello_world_stream_with_badbit_throws_runtime_error\": std::runtime_error not thrown\r\n\r\n*** 1 failure detected in test suite \"Master Test Suite\"\r\n \r\nEXIT STATUS: 201 \r\n]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_exceptions/2/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nalias testing_with_exceptions.2 :\n hello.testing_with_exceptions.2\n test_hello.testing_with_exceptions.2\n ;\n\nlib hello.testing_with_exceptions.2 : sut/hello.cpp : static ;\nrun-fail test/test_hello.cpp hello.testing_with_exceptions.2 : : : sut : test_hello.testing_with_exceptions.2 ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_exceptions/2/sut/hello.cpp",
"content": "#include \"hello.hpp\"\n\n//[ testing_with_exceptions_sut_hello_cpp_2\nvoid hello_world(std::ostream& stream)\n{\n if (stream.bad())\n {\n throw std::runtime_error(\"bad stream\");\n }\n stream << \"Hello, world!\\n\";\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_exceptions/2/sut/hello.hpp",
"content": "//[ testing_with_exceptions_sut_hpp_1\n#if !defined(HELLO_HPP)\n#define HELLO_HPP\n\n#include \n\nextern void hello_world(std::ostream& stream);\n\n#endif\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_exceptions/2/test/test_hello.cpp",
"content": "#define BOOST_TEST_MAIN\n#include \n#include \"hello.hpp\"\n#include \n#include \n\nBOOST_AUTO_TEST_CASE(hello_world_inserts_text)\n{\n std::ostringstream dest;\n\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n\n//[ hello_world_stream_with_badbit_throws_runtime_error_1\nBOOST_AUTO_TEST_CASE(hello_world_stream_with_badbit_throws_runtime_error)\n{\n std::ostringstream dest;\n dest.clear(std::ios_base::badbit);\n\n hello_world(dest);\n\n BOOST_FAIL(\"std::runtime_error not thrown\");\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_exceptions/2/test_hello~testing_with_exceptions~2.output",
"content": "[pre\r\nRunning 2 test cases...\r\nunknown location(0): fatal error in \"hello_world_stream_with_badbit_throws_runtime_error\": std::runtime_error: bad stream\r\nsrc/tutorials/testing_with_exceptions/2/test/test_hello.cpp(13): last checkpoint\r\n\r\n*** 1 failure detected in test suite \"Master Test Suite\"\r\n \r\nEXIT STATUS: 201 \r\n]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_exceptions/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nalias testing_with_exceptions :\n 1//testing_with_exceptions.1\n 2//testing_with_exceptions.2\n test_hello.testing_with_exceptions\n ;\n\nlib hello.testing_with_exceptions : sut/hello.cpp : static ;\nrun test/test_hello.cpp hello.testing_with_exceptions : : : sut : test_hello.testing_with_exceptions ;\n\nbuild-project 1 ;\nbuild-project 2 ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_exceptions/sut/hello.cpp",
"content": "//[ testing_with_exceptions_sut_cpp\n#include \"hello.hpp\"\n\nvoid hello_world(std::ostream& stream)\n{\n if (stream.bad())\n {\n throw std::runtime_error(\"bad stream\");\n }\n stream << \"Hello, world!\\n\";\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_exceptions/sut/hello.hpp",
"content": "//[ testing_with_exceptions_sut_hpp\n#if !defined(HELLO_HPP)\n#define HELLO_HPP\n\n#include \n\nextern void hello_world(std::ostream& stream);\n\n#endif\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_exceptions/test/test_hello.cpp",
"content": "#define BOOST_TEST_MAIN\n#include \n#include \"hello.hpp\"\n#include \n#include \n\nBOOST_AUTO_TEST_CASE(hello_world_inserts_text)\n{\n std::ostringstream dest;\n\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n\n//[ hello_world_stream_with_badbit_throws_runtime_error\nBOOST_AUTO_TEST_CASE(hello_world_stream_with_badbit_throws_runtime_error)\n{\n std::ostringstream dest;\n dest.clear(std::ios_base::badbit);\n\n BOOST_REQUIRE_THROW(hello_world(dest), std::runtime_error);\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_exceptions/test_hello~testing_with_exceptions.output",
"content": "[pre\r\nRunning 2 test cases...\r\n\r\n*** No errors detected\r\n \r\nEXIT STATUS: 0 \r\n]\r\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_fixtures/1/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nalias testing_with_fixtures.1 :\n hello.testing_with_fixtures.1\n test_hello.testing_with_fixtures.1\n ;\n\nlib hello.testing_with_fixtures.1 : sut/hello.cpp : static ;\nrun test/test_hello.cpp hello.testing_with_fixtures.1 : : : sut : test_hello.testing_with_fixtures.1 ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_fixtures/1/sut/hello.cpp",
"content": "#include \"hello.hpp\"\n\nvoid hello_world(std::ostream& stream)\n{\n if (stream.bad())\n {\n throw std::runtime_error(\"bad stream\");\n }\n stream << \"Hello, world!\\n\";\n}\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_fixtures/1/sut/hello.hpp",
"content": "#if !defined(HELLO_HPP)\n#define HELLO_HPP\n\n#include \n\nextern void hello_world(std::ostream& stream);\n\n#endif\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_fixtures/1/test/test_hello.cpp",
"content": "#define BOOST_TEST_MAIN\n#include \n#include \"hello.hpp\"\n#include \n#include \n\n//[testing_with_fixtures_test_cpp_1\nstruct hello_world_fixture\n{\n hello_world_fixture()\n : dest()\n { }\n ~hello_world_fixture()\n { }\n\n std::ostringstream dest;\n};\n\nBOOST_FIXTURE_TEST_CASE(hello_world_inserts_text, hello_world_fixture)\n{\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n\nBOOST_FIXTURE_TEST_CASE(hello_world_stream_with_badbit_throws_runtime_error, hello_world_fixture)\n{\n dest.clear(std::ios_base::badbit);\n\n BOOST_REQUIRE_THROW(hello_world(dest), std::runtime_error);\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_fixtures/Jamfile.v2",
"content": "# Jamfile.v2\n#\n# Copyright (c) 2013\n# Richard Thomson\n#\n# Distributed Under the Boost Software License, Version 1.0. (See\n# accompanying file LICENSE_1_0.txt or copy at\n# http://www.boost.org/LICENSE_1_0.txt)\n\nalias testing_with_fixtures :\n 1//testing_with_fixtures.1\n test_hello.testing_with_fixtures\n ;\n\nlib hello.testing_with_fixtures : sut/hello.cpp : static ;\nrun test/test_hello.cpp hello.testing_with_fixtures : : : sut : test_hello.testing_with_fixtures ;\n\nbuild-project 1 ;\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_fixtures/sut/hello.cpp",
"content": "#include \"hello.hpp\"\n\nvoid hello_world(std::ostream& stream)\n{\n if (stream.bad())\n {\n throw std::runtime_error(\"bad stream\");\n }\n stream << \"Hello, world!\\n\";\n}\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_fixtures/sut/hello.hpp",
"content": "#if !defined(HELLO_HPP)\n#define HELLO_HPP\n\n#include \n\nextern void hello_world(std::ostream& stream);\n\n#endif\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials/testing_with_fixtures/test/test_hello.cpp",
"content": "#define BOOST_TEST_MAIN\n#include \n#include \"hello.hpp\"\n#include \n#include \n\n//[testing_with_fixtures_test_cpp\nstruct hello_world_fixture\n{\n std::ostringstream dest;\n};\n\n#define HELLO_WORLD_TEST_CASE(name_) \\\n BOOST_FIXTURE_TEST_CASE(hello_world_##name_, hello_world_fixture)\n\nHELLO_WORLD_TEST_CASE(inserts_text)\n{\n hello_world(dest);\n\n BOOST_REQUIRE_EQUAL(\"Hello, world!\\n\", dest.str());\n}\n\nHELLO_WORLD_TEST_CASE(stream_with_badbit_throws_runtime_error)\n{\n dest.clear(std::ios_base::badbit);\n\n BOOST_REQUIRE_THROW(hello_world(dest), std::runtime_error);\n}\n//]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/tutorials.qbk",
"content": "[/==============================================================================\n Copyright (C) 2013 Richard Thomson\n\n Distributed under the Boost Software License, Version 1.0. (See accompanying\n file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)\n===============================================================================/]\n\n[section:tutorials Tutorials]\n\nThese tutorials will get you started using __test__. They are intended\nto be read in order and proceed from the basics of [link test.tutorials.hello_test\nwriting your first test] to [link test.tutorials.running_selected_tests\nrunning selected tests]. Once you've finished with the tutorials, you\nmay want to read about [link test.guide.test_case_design test case design]\nfor some suggestions on testing various situations in C++. The full\ndetails of the framework are provided in the [link test.reference reference]\nsection.\n\n[/----------------------------------------------------------------------]\n[section:hello_test Hello, Test!]\nSuppose we wish to test that the following function, declared in =hello.hpp=\nand supplied by a static library =hello=, inserted the text\n=Hello, world!\\n= to the given =stream=:\n\n[import tutorials/hello_test/1/sut/hello.hpp]\n[hello_test_sut_hpp1]\n\nWe can accomplish this with the following test, saving it in =test_hello.cpp=:\n\n[import tutorials/hello_test/1/test/test_hello.cpp]\n[hello_test_test_cpp1]\n\nWe compile =test_hello.cpp= and link it against the static library =hello=\nusing the build environment for our platform to produce an executable.\nNo other source files or libraries are needed.\nWhen we run the executable, it will execute our test case.\n\nSuppose that our implementation of =hello_world= looks like this:\n\n[import tutorials/hello_test/1/sut/hello.cpp]\n[hello_test_sut_cpp1]\n\nWhen we run the unit test executable we obtain output similar to the\nfollowing:[footnote\nThe test runner output here is generated from the =run-fail= rule in\nBoost.Build which includes the output from the executable and appends\nthe exit code of the process to the output.]\n\n[include tutorials/hello_test/1/hello_test~1.output]\n\nOops, it looks like we forgot to implement =hello_world=!. Let's fix that\nby changing =hello.cpp= to the following:\n\n[import tutorials/hello_test/2/sut/hello.cpp]\n[hello_test_sut_cpp2]\n\nWe can now rebuild our library, relink our unit test executable and re-run\nthe test:\n\n[include tutorials/hello_test/2/hello_test~2.output]\n\nOops, looks like we forgot to insert the newline character. Let's fix that\nby changing =hello.cpp= to the following:\n\n[import tutorials/hello_test/3/sut/hello.cpp]\n[hello_test_sut_cpp3]\n\nWe rebuild our library, relink our unit test executable again and re-run\nthe test:\n\n[include tutorials/hello_test/3/hello_test~3.output]\n\nNow all our tests are passing and we know that =hello_world= does what\nwe expect it to do. We used =std::endl= to insert the newline character\nand it also flushes the output stream after inserting the newline. If\nwe didn't want the output stream to be flushed, we can change =hello_world=\nto use a character literal:\n\n[import tutorials/hello_test/sut/hello.cpp]\n[hello_test_sut_cpp]\n\nWe rebuild and re-run the test to verify that our change didn't break\nanything:\n\n[include tutorials/hello_test/hello_test.output]\n\n[heading Some Observations]\n\nNow that we've seen __test__ in action, let's take a closer look at\nwhat we have just done:\n\n* The entire unit test framework was brought into our test application\n with a single include ==. We didn't\n link against any libraries or introduce any run-time dependencies.\n* We didn't write an implementation of =main=, but our test executable\n linked and ran. Why? The preprocessor symbol __boost_test_main__\n instructed __test__ to supply an implementation of =main= that executes\n all tests registered with the framework.\n* The macro __boost_auto_test_case__ registered our unit test case with\n the framework and provides the necessary preamble for the implementation\n of the testing function.\n* The argument to __boost_auto_test_case__ is the name of our test case and\n is a C++ identifier, not a string.\n* The test was structured in three phases: setup, exercise, and verify.\n * Our setup phase created an output string stream in order to capture\n the output of =hello_world=, the system under test.\n * The exercise phase called the system under test, our function =hello_world=.\n * The verify phase checked that the function provided the expected output\n using the assertion macro __boost_require_equal__.\n * To make the phases of the test obvious, we used blank lines to separate them.\n* A failing test emits a message that provides information about the\n location of the failed assertion and the detail of the failure.\n* The above sequence is a typical example of test-driven development,\n proceeding through stages of \"red\", \"green\" and \"refactor\".\n * We wrote a failing test and just enough implementation to compile the\n test (\"red\").\n * We then wrote the implementation and ran the test to verify our\n implementation. We made a simple mistake, so we corrected that and\n re-ran the test to verify our implementation by passing the test (\"green\").\n * Once our implementation was correct, we looked at possible improvements\n we might make to the code; in our case we eliminated the side-effect\n of flushing the output stream (\"refactor\").\n* The test code and production code, or system under test, are kept\n separate. The production code was in a library and the test code was\n in an executable.\n* No news is good news! We don't see any noise from test cases when\n they pass and the test executable emits only a summary of all test\n cases when all tests pass.\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/tutorials/hello_test/sut/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/tutorials/hello_test/sut/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/tutorials/hello_test/test/test_hello.cpp test_hello.cpp]\n\n[endsect]\n\n[/----------------------------------------------------------------------]\n[section:testing_with_exceptions Testing with Exceptions]\n\nWhen we're testing a system, we want to test the failure cases\nas well as the success cases. This means forcing the system under test\ndown an error path by orchestrating bad inputs or synthesizing errors\nfrom code collaborating with the system under test.\n\nLet's add the requirement that [link test.tutorials.hello_test =hello_world=]\nshould throw the a =std::runtime_error= exception if the supplied stream\nhas the =badbit= set on the stream.\n\nWe can add a test case for this:\n\n[import tutorials/testing_with_exceptions/1/test/test_hello.cpp]\n[hello_world_stream_with_badbit_throws_runtime_error_1]\n\n[note The [@http://en.cppreference.com/w/cpp/io/basic_ios/clear =clear=\nmember function] on a stream clears all state bits and sets the state to\nthe value of the argument.]\n\nInstead of an assertion macro like __boost_require_equal__, we're using\nthe __boost_fail__ macro that guarantees test failure. If the call to\n=hello_world= doesn't throw a =runtime_error= exception and continues\nto the next line of code, then this test case fails:\n\n[include tutorials/testing_with_exceptions/1/test_hello~testing_with_exceptions~1.output]\n\nNow let's enhance the implementation to support this requirement:\n\n[import tutorials/testing_with_exceptions/2/sut/hello.cpp]\n[testing_with_exceptions_sut_hello_cpp_2]\n\nWe run our test and get something similar to the following:\n\n[include tutorials/testing_with_exceptions/2/test_hello~testing_with_exceptions~2.output]\n\nNow the test is still failing, so what did we do wrong? The\nexception from our system under test unwound the call stack back into the\nunit test framework, which caught the exception and reported this as a\nfailure. We need to tell the test framework that an exception is expected\nin this situation. We can use __boost_require_throw__ to tell the test\nframework that an expression is expected to throw a particular type of\nexception. If the exception isn't thrown or an exception of a different\ntype is thrown, then the test fails. Our test now looks like this:\n\n[import tutorials/testing_with_exceptions/test/test_hello.cpp]\n[hello_world_stream_with_badbit_throws_runtime_error]\n\nNow our test case is passing:\n\n[include tutorials/testing_with_exceptions/test_hello~testing_with_exceptions.output]\n\n[heading Some Observations]\n\n* We gave our test case a name that revealed the essence of what it tests\n so that when it fails, we know immediately from the name of the test what\n requirement has been invalidated. Using intention revealing names for\n test cases is just as important as using intention revealing names for\n methods, functions and classes.\n* We kept each scenario we wanted to test separate and independent from\n each other. This keeps our tests robust; the state of one test does\n not interfere with any other test.\n* Now that we have two test cases, we can see that there is some duplication\n between them: the construction of an output string stream. It isn't much\n right now, just a single line, but duplication between tests is something\n we'll need to watch.\n* Every time we modify or add a test, we have to recompile our single\n test file =test_hello.cpp=, which is including the entire unit test\n framework source. This leads to a lengthy compile every time we\n have to change the tests.\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/tutorials/testing_with_exceptions/sut/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/tutorials/testing_with_exceptions/sut/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/tutorials/testing_with_exceptions/test/test_hello.cpp test_hello.cpp]\n\n[endsect]\n\n[/----------------------------------------------------------------------]\n[section:testing_with_fixtures Testing with Fixtures]\n\nWhen we added our second test case in the\n[link test.tutorials.testing_with_exceptions previous tutorial], we\nended up with some duplicated setup between the two test cases. This is\na common occurrence in unit testing. We have some prerequisites for the\nsystem under test that must be prepared in order to exercise the system.\nIn our case, it is a single output string stream that we use for capturing\nthe output of our =hello_world= function.\n\n__test__ provides a facility called a fixture for encapsulating repeated\nsetup and tear down code between test cases. In our example, there isn't\nany explicit tear down code because the output string streams are created\non the stack and destroyed when execution exits the test case. We have a\nlittle bit of repeated setup code that we can move to a fixture that is\nused by both our test cases. Let's put that repeated code in a fixture:\n\n[import tutorials/testing_with_fixtures/1/test/test_hello.cpp]\n[testing_with_fixtures_test_cpp_1]\n\nA fixture is simply a class or struct that is inherited by the test case.\nWe connect the test case to the fixture by using __boost_fixture_test_case__\ninstead of __boost_auto_test_case__. The latter simply connects each test\ncase to an empty fixture. After refactoring the test cases to use a\nfixture, we run the tests to make sure the tests still pass.\n\nWhen using a fixture, the order of construction and destruction is as\nfollows when a test case is executed:\n\n# The fixture is constructed.\n# The test case class is constructed.\n# The test case test method is executed\n# The test case class is destroyed.\n# The fixture is destroyed.\n\nThis process happens for each test case that is executed, ensuring that\neach test case has a fresh fixture and remains independent of other test\ncases.\n\nIn most cases, the setup will be a little more involved than just creating\nan instance variable and there will be some work done in the constructor of\nthe fixture. We could simply use the default constructor and destructor of\nour fixture in this case. We've written the constructor and destructor\nexplicitly to emphasize that this is where setup and tear down occur.\n\nNow that we've transformed the test cases to use a fixture, it seems\nwe've simply traded one piece of repetition, the construction of the\noutput string stream, for another: the repeated use of the fixture\nname and system under test in our test cases. We can use a custom test\ncase macro to get rid of this duplication:\n\n[import tutorials/testing_with_fixtures/test/test_hello.cpp]\n[testing_with_fixtures_test_cpp]\n\nEvery test case has to have a unique name within the scope of its\ndeclaration, either the global namespace or a custom namespace, which is\nwhy we've been prefixing our test case names with the name of the system\nunder test, =hello_world=. Once we accumulate a few tests, the chances\nfor a clash between test names increases.\n\nWith our custom test case macro, we reduce the chance for a test case\nname clash by ensuring that every test case name is prefixed by the\nname of the system under test. We ensure that every test case\nfor =hello_world= uses the same fixture and we gain some readability of\nthe test cases by eliminating the distracting repetition. If we change\nthe name of the fixture, then we need only edit the custom test case\nmacro that supplies the fixture name.\n\nIn the next tutorial, we'll see an alternative way of eliminating this\nduplication of the prefixes of test case names.\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/tutorials/testing_with_fixtures/sut/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/tutorials/testing_with_fixtures/sut/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/tutorials/testing_with_fixtures/test/test_hello.cpp test_hello.cpp]\n\n[endsect]\n\n[/----------------------------------------------------------------------]\n[section:running_selected_tests Running Selected Tests]\n\nAs we continue to add unit tests for a library, we can get quite a large\nnumber of tests. If they are true unit tests and each test exercises a\nsingle class isolated from its collaborators, then most of the tests are\nnot relevant to the changes we are making. The test executable accepts\na number of command-line arguments that allow us to control the behavior\nof the test framework, including which tests to run.\n\nWe can list the available tests in a test executable with __report_level__\nset to detailed:\n\n[include tutorials/running_selected_tests/1/report_level_detailed.output]\n\n[caution The arguments to the test executable, such as __report_level__,\nuse an underscore (=_=) to separate words, not a dash (=-=).]\n\nSuppose we are continuing to make changes to =hello_world= and we want\nto run only the tests that apply to that function. We can easily identify\nthe relevant tests in the output of __report_level__ because we have used\na test naming convention of prefixing all test case names with the name\nof the system under test, =hello_world=.\n\nUsing the __run_test__ argument, we can specify a comma-separated list\nof test case names to run:\n\n[include tutorials/running_selected_tests/1/test_hello~running_selected_tests~1.output]\n\nWow, that's really a mouthfull! Even with command recall, typing this\ncommand for the first time will require typing the exact names of all the\ntest cases for =hello_world=. As we add more test cases, we'll have to\nextend the command line argument to account for each new test case.\n\nWe can solve this problem by using test suites, which organize tests into\na named group:\n\n[import tutorials/running_selected_tests/2/test/test_hello.cpp]\n[running_selected_tests_test_cpp_2]\n\nNow __report_level__ outputs the following:\n\n[include tutorials/running_selected_tests/2/report_level_detailed.output]\n\nThe indentation shows that the test cases for =hello_world= are organized\nunder the test suite named =test_hello_world=.\n\n[note We can't name the suite =hello_world= because that would conflict\nwith the name of our system under test, as both are declared in the same\nglobal namespace.]\n\nNow we can supply the name of the test suite to __run_test__ to run all\nthe test cases in the suite:\n\n[include tutorials/running_selected_tests/2/test_hello~running_selected_tests~2.output]\n\nAs we add more test cases to the suite, we don't have to change the\ncommand we are using to run the tests and we don't need to remember the\nexact names of the test cases.\n\nSuites arrange test cases into a hierarchy. You can have suites within\nsuites to provide larger groupings to test a collection of related classes\ntogether. Once a test case is part of a suite, we must use the name of\nthe enclosing suite with the name of the test case if we wish to run a\nsingle test case within the suite by name:\n\n[include tutorials/running_selected_tests/2/run_test_hello_inserts_text.output]\n\nThe names of the enclosing suites are separated from each other and from\nthe test case name with a slash (=/=). The names supplied to __run_test__\nalso allow for wildcard matching:\n\n[include tutorials/running_selected_tests/2/run_test_hello_star_inserts_text.output]\n\nJust as we can use a fixture with a test case to eliminate repeated setup\nand tear down, we can use a fixture with a test suite. All test cases\nin the test suite will derive from the test suite's fixture. If a test\ncase in a test suite with a fixture specifies its own fixture, then the\ntest case derives from the fixture specified on the test case and not on\nthe test suite. If you want the test case to use both fixtures, then\nmake your test case fixture derive from the test suite fixture.\n\nWe can use a test suite fixture for =test_hello= to take care of the\nduplicated setup between test cases. Since our test cases are now within\nthe scope of a suite, we don't need to give them a unique prefix anymore.\nRefactoring the tests to use a suite fixture and discarding the prefix\ngives us the following code:\n\n[import tutorials/running_selected_tests/test/test_hello.cpp]\n[running_selected_tests_test_cpp]\n\nNow __report_level__ outputs the following:\n\n[include tutorials/running_selected_tests/report_level_detailed.output]\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/tutorials/running_selected_tests/sut/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/tutorials/running_selected_tests/sut/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/tutorials/running_selected_tests/test/test_hello.cpp test_hello.cpp]\n\n[endsect]\n\n[endsect]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/user-compilation.qbk",
"content": "[/==============================================================================\n Copyright (C) 2013 Richard Thomson\n\n Distributed under the Boost Software License, Version 1.0. (See accompanying\n file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)\n===============================================================================/]\n\n[section:compilation Compilation and Usage Variants]\n\n__test__ is available in several forms:\n\n* a single, minimal header\n* a header-only form\n* a static library\n* a shared library\n\nThe minimal header can be useful in situations where you don't already\nhave the library built and want to quickly explore a test with a minimal\namount of fuss. Once you need to create multiple unit tests, you will\nquickly outgrow the minimal header.\n\nThe header only form is useful when you don't want to be bothered with\ncompiling the library. Once you have multiple compilation units with\nunit tests in each compilation unit, you will grow tired of the compilation\ncost involved with the header only form of the framework.\n\nThe static library form is the easiest to integrate into your build system\nas it doesn't require any installation of runtime files in order to execute\nyour tests. This runtime simplicity comes at the cost of increased link\ntimes and executable sizes.\n\nThe dynamic library form requires the most effort for successful\ntest execution, but provides faster link times than the static library,\nfaster compile times than the header only form and provides all the features\nof the framework compared to the minimal header.\n\n[caution __test__ is not a thread-safe library. Care should be taken when\nautomated tests create multiple threads and interact with data structures\npassed to __test__ macros or functions.]\n\n[section:minimal_header Minimal Header]\n\nA lightweight, minimal version of the testing framework can be obtained\nby including ==. This header provides only the\nfollowing macros:\n\n[table\n[[Macro] [Meaning]]\n[[=BOOST_CHECK(=['expression]=)=]\n [If ['expression] is false, the test fails and test execution continues.]]\n[[=BOOST_REQUIRE(=['expression]=)=]\n [If ['expression] is false, the test fails and test execution terminates.]]\n[[=BOOST_ERROR(=['message]=)=]\n [Report ['message], fail the test and continue test execution.]]\n[[=BOOST_FAIL(=['message]=)=]\n [Report ['message], fail the test and terminate test execution.]]\n]\n\nThe header supplies an implementation of =main= that executes a single\ntest case by calling a free function named =test_main= with the following\nsignature:\n\n```\nint test_main(int argc, char *argv[]);\n```\n\nThe arguments =argc= and =argv= are passed to =test_main= from the\nimplementation of =main= supplied by the test framework. No command-line\nargument processing is performed by =main=. A summary report of errors\nrecorded by the test case is printed out after executing the test case.\nIf any exception is thrown by the test case, it is caught by =main=\nand treated as an error from the test case.\n\n```\n#include \n\nint test_main(int argc, char *argv[])\n{\n // test case\n}\n```\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.cpp hello.cpp]\n* An example of using the minimal test framework:\n * [@boost:/libs/test/doc/src/examples/compilation/minimal/test_hello.cpp test_hello.cpp].\n\n[endsect]\n\n[section =main=]\n\nTo use the implementation of =main= provided by __test__, exactly one\nsource file must define __boost_test_main__ before including\n==. If multiple source files define\n__boost_test_main__, then a multiply defined symbol error will occur\nduring linking.\n\nIf __boost_test_no_main__ is defined, then no implementation of =main=\nwill be provided and the test executable must provide an initialization\nfunction. The exact initialization function that must be provided varies\ndepending on how the library is compiled. The details are shown in the\ndiscussion of each compilation variation.\n\nWhen __test__ is compiled as a library, __boost_test_no_main__ must be\ndefined when the library is compiled for it to work properly in those\ncircumstances.\n\n[endsect]\n\n[section:header_only Header Only]\n\nThe entire unit test framework can be incorporated into an executable by\nincluding the file ==. Because the\nentire implementation is incorporated into the source file including\nthis header, only a single source file in the test executable can\ninclude this header.\n\nAdditional source files must define __boost_test_no_lib__ before\nincluding == to prevent any automatic linking\nto a shared library. If additional source files attempt to include\n==, a multiply defined symbol error\nwill occur during linking.\n\n```\n// In exactly one source file:\n#include \n\n// test cases (optional)\n```\n```\n// In additional source files\n#define BOOST_TEST_NO_LIB\n#include \n\n// test cases\n```\n\nIf __boost_test_no_main__ is defined, then an implementation of =main=\nmust be provided that executes the test cases. This is most readily\ndone by delegating to __unit_test_main__.\n\n```\n// In exactly one source file\n#define BOOST_TEST_NO_MAIN\n#include \n\nboost::unit_test::test_suite *init_function(int argc, char *argv[])\n{\n // create test cases and suites and return a pointer to any enclosing\n // suite, or 0.\n return 0;\n}\n\nint main(int argc, char* argv[])\n{\n return ::boost::unit_test::unit_test_main(&init_function, argc, argv);\n}\n```\n\n[heading Example Source Code]\n\nThe [link test.tutorials tutorials] all use the header-only version of\n__test__.\n\n[endsect]\n\n[section Static Library]\n\nTo build __test__ as a static library, first build the boost build tools,\nas described in the [@boost:/more/getting_started/index.html Getting Started]\ndocumentation. After you have bootstrapped the build tools, build the test\nlibrary with by invoking =b2= with arguments similar to the following:\n\n``b2 --with-test link=static``\n\nThis will place the resulting libraries in =stage/lib= at the top level\nof the boost tree.\n\nIn a static library configuration, __test__ is compiled into a single\nstatic library named =boost_unit_test_framework= and the test executable\nis linked against that library.\nExactly one compilation unit in the test executable should define\n__boost_test_main__, in order run the tests.\n\n```\n// In exactly one source file\n#define BOOST_TEST_MAIN\n#include \n\n// test cases (optional)\n```\n\nAdditional source files simply include the main unit test header and\ndefine more test cases and/or suites.\n\n```\n// In additional source files\n#include \n\n// test cases\n```\n\nTo compile the library with no implementation of =main=, add\n__boost_test_no_main__ to the =cxxflags= property for b2:\n\n``b2 --with-test link=static define=BOOST_TEST_NO_MAIN``\n\nWhen the library is compiled with __boost_test_no_main__ defined, one\nsource file must provide a definition for =main=. The simplest is\nto delegate to __unit_test_main__ and provide an implementation of an\ninitialization function that manually adds test cases and suites to the\ntest tree.\nAny test cases or test suites added with\n__boost_auto_test_case__, __boost_fixture_test_case__,\n__boost_auto_test_suite__ or __boost_fixture_test_suite__ are automatically\nadded.\n\n```\n// In exactly one source file\n#define BOOST_TEST_NO_MAIN\n#include \n\nboost::unit_test::test_suite *init_function(int argc, char *argv[])\n{\n // create test cases and suites and return a pointer to any enclosing\n // suite, or 0.\n return 0;\n}\n\nint main(int argc, char *argv[])\n{\n return boost::unit_test::unit_test_main(init_function, argc, argv);\n}\n```\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.cpp hello.cpp].\n* An example of using the standard implementation of =main=:\n * [@boost:/libs/test/doc/src/examples/compilation/static/main.cpp main.cpp]\n * [@boost:/libs/test/doc/src/examples/compilation/static/test_hello.cpp test_hello.cpp].\n* An example of using a custom =main=:\n * [@boost:/libs/test/doc/src/examples/compilation/static_main/main.cpp main.cpp]\n * [@boost:/libs/test/doc/src/examples/compilation/static_main/test_hello.cpp test_hello.cpp].\n\n[endsect]\n\n[section Shared Library]\n\nTo build __test__ as a shared library, first build the boost build tools,\nas described in the [@boost:/more/getting_started/index.html Getting Started]\ndocumentation. After you have bootstrapped the build tools, build the test\nlibrary with by invoking =b2= with arguments similar to the following:\n\n``b2 --with-test link=shared``\n\nThis will place the resulting libraries in =stage/lib= at the top level\nof the boost tree.\n\nIn a shared library configuration, __test__ is compiled into a single\nshared library named =boost_unit_test_framework= and the test executable\nis linked against that library to import symbols from the library.\nThe __test__ shared library must\nbe available to the runtime loader in order for the tests to execute.\nEvery compilation unit that includes a header from __test__ must define\n__boost_test_dyn_link__ first so that declarations are properly annotated\n as imported symbols. When __boost_test_dyn_link__ is defined, __test__\nalso defines __boost_test_alternative_init_api__.\n\nExactly one compilation unit in the test executable should define\n__boost_test_main__, in order run the tests.\n\n```\n// In exactly one compilation unit\n#define BOOST_TEST_DYN_LINK\n#define BOOST_TEST_MAIN\n#include \n\n// test cases (optional)\n```\n\nAdditional source files define __boost_test_dyn_link__, include the\nmain unit test header and define more test cases and/or suites.\n\n```\n// In additional source files\n#define BOOST_TEST_DYN_LINK\n#include \n\n// test cases\n```\n\nTo compile the library with no implementation of =main=, add\n__boost_test_no_main__ to the =cxxflags= property for b2:\n\n``b2 --with-test link=shared define=BOOST_TEST_NO_MAIN``\n\nWhen the library is compiled with __boost_test_no_main__ defined, one\nsource file must provide a definition for =main=. The simplest is\nto delegate to __unit_test_main__ and provide an implementation of an\ninitialization function that manually adds test cases and suites to the\ntest tree.\nAny test cases or test suites added with\n__boost_auto_test_case__, __boost_fixture_test_case__,\n__boost_auto_test_suite__ or __boost_fixture_test_suite__ are automatically\nadded.\n\n```\n// In exactly one source file\n#define BOOST_TEST_NO_MAIN\n#include \n\nbool init_function()\n{\n // create test cases and suites and return a boolean indicating\n // success (true) or failure (false).\n return true;\n}\n\nint main(int argc, char* argv[])\n{\n return ::boost::unit_test::unit_test_main(&init_function, argc, argv);\n}\n```\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.cpp hello.cpp]\n* An example of using the standard implementation of =main=:\n * [@boost:/libs/test/doc/src/examples/compilation/dynamic/main.cpp main.cpp]\n * [@boost:/libs/test/doc/src/examples/compilation/dynamic/test_hello.cpp test_hello.cpp].\n* An example of using a custom =main=:\n * [@boost:/libs/test/doc/src/examples/compilation/dynamic_main/main.cpp main.cpp]\n * [@boost:/libs/test/doc/src/examples/compilation/dynamic_main/test_hello.cpp test_hello.cpp].\n\n[endsect]\n\n[endsect]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/src/user-guide.qbk",
"content": "[/==============================================================================\n Copyright (C) 2013 Richard Thomson\n\n Distributed under the Boost Software License, Version 1.0. (See accompanying\n file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)\n===============================================================================/]\n\n[section:guide User's Guide]\n\n[include:test user-compilation.qbk]\n\n[section:test_case_design Test Case Design and Maintenance]\n\n[@http://xunitpatterns.com/Goals%20of%20Test%20Automation.html xUnit\nPatterns][footnote The term ['xUnit] is a generic term for unit testing\nframeworks, such as jUnit. The advice in ['xUnit Patterns] applies equally\nwell to __test__.], by Gerard Meszaros, presents several high level\nobjectives for automated tests and individual goals for achieving those\nobjectives:\n\n* Objective: Tests should help us improve quality.\n * Goal: [link tests_as_specifications Tests as specifications]\n * Goal: [link bug_repellant Bug repellant]\n * Goal: [link defect_localization Defect localization]\n* Objective: Tests should help us understand the system under test.\n * Goal: [link tests_as_documentation Tests as documentation]\n* Objective: Tests should reduce, not increase, risk.\n * Goal: [link tests_as_safety_net Tests as safety net]\n * Goal: [link do_no_harm Do No Harm]\n* Objective: Tests should be easy to run.\n * Goal: [link fully_automated_test Fully Automated Test]\n * Goal: [link self_checking_test Self-Checking Test]\n * Goal: [link repeatable_test Repeatable Test]\n* Objective: Tests should be easy to write and maintain.\n * Goal: [link simple_tests Simple Tests]\n * Goal: [link expressive_tests Expressive Tests]\n * Goal: [link separation_of_concerns Separation of Concerns]\n* Objective: Tests should require minimal maintenance as the system evolves\n around them.\n * Goal: [link robust_test Robust Test]\n\nIn this section, we will discuss how the facilities in __test__ can support\nthese goals; see ['xUnit Patterns] for the description and rationale of\nthese goals.\n\n[#tests_as_specifications][heading Goal: Tests as Specifications]\n\nTests can serve as specifications for the system under test if we write\nthe test for the system first, using test-driven development. We imagine\nthe perfect system that does exactly what we need and write a test as if\nthat system existed. In order to achieve a failing test, we write just\nenough of the implementation to make the test compile.\n\nA good way to ensure that the implementation causes a test failure is for\ncalled methods and functions to throw an exception indicating that the\nmethod or function called is not implemented:\n```\n#include \n\nvoid free_function()\n{\n throw std::runtime_error(\"free_function not implemented.\");\n}\n```\nWe get a failing test right away, while still satisfying just enough syntax\nto satisfy the compiler.\n\n[#bug_repellant][heading Goal: Bug Repellant]\n\nIt is well known that the longer a bug remains undetected in a software,\nthe more expensive it is to fix.[footnote\n[@https://en.wikipedia.org/wiki/Software_testing#Economics Software Testing:\nEconomics]] If we are practicing test-driven development, then we find\nbugs in our implementation as soon as we code them. The time to find a\nbug in this manner can be as little as seconds and was demonstrated in\nthe tutorial [link test.tutorials.hello_test \"Hello, Test!\"].\n\nThe easiest way to achieve this rapid feedback is to run the tests as part\nof the build. The details vary depending on your build system.\n\nIn Visual Studio 2012, this is most readily achieved by setting a post-build\nbuild event as shown below. Because [^$(TargetPath)] may contain spaces,\nthe variable is surrounded by double quotes to ensure that the entire path\nto the executable is found. The description is given generically using\n[^$(TargetName)] so that this build event can be copied to any test\nproject's properties and be used without modification. Take\ncare that you define the build event for all configurations and all\nplatforms used by your build system so that the unit tests always run. \n\n[$../src/user-vs2012-build-event.png]\n\nIf you are using a =Makefile= to compile your code, create a phony\ntarget that depends on your unit test executable and specify the\ncommand to execute your unit test and create the phony target if\nthe test passes. This will ensure that the unit tests continue to run\nas long as they fail because the phony target will only be updated\nwhen the tests pass.\n\nIf you are using Boost.Build and Jamfiles to compile your code, you can\nuse the rules in the =testing= module to incorporate your unit tests\ninto your build. The =unit-test= rule will build an executable and run\nit, failing the build when the executable returns a non-zero exit status.\nOther rules in the =testing= module may also be useful.\n\n[#defect_localization][heading Goal: Defect Localization]\n\nIf we keep our test cases focused on only a single behavior in our\nsystem under test, then there is only a single cause for any particular\nunit test to fail. We saw this in [link\ntest.tutorials.testing_with_exceptions \"Testing With Exceptions\"] when\nwe added a new test case to =hello_world= for a bad stream. By choosing\n[@http://c2.com/cgi/wiki?IntentionRevealingNames intention revealing names]\nfor our test cases, we can identify the source of the failure simply by\nreading the name of the failed test case.\n\nSince each test case excercises only one scenario for the system under\ntest, we must make at least one test case for each possible scenario. We\ncan use the [@http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic\ncomplexity] as a rough proxy for the number of tests cases needed for any\nparticular method or function to ensure that we have sufficient\n[@http://en.wikipedia.org/wiki/Code_coverage coverage] of the system under\ntest.\n\n[#tests_as_documentation][heading Goal: Tests as Documentation]\n\nWhen confronted with a new software component or a new code base, how do\nwe understand its behavior? We can read the documentation, but ultimately\nthe behavior is defined by the code executed. Comments and documentation\ncan lag the actual implementation. Sometimes, the only answer to our\nquestions about a software component come from the implementation. If\nthe component is only available to us in binary form, we don't have the\nluxury of consulting the source code in order to answer our questions.\n\nUnit tests can serve as a form of executable documentation for software\ncomponents. They tell us how the system responds to the scenarios\norchestrated by the test cases.\n\nWhen faced with a confusing aspect of a software component, we can answer\nquestions about the behavior of the component by writing a unit test that\ndescribes our hypothesis about the component's behavior. If the unit test\npasses, we have verified our hypothesis. If the unit test fails, our\nhypothesis was incorrect; either way, we have learned something about the\ncomponent. We can use unit tests to document subtle and unexpected\nbehaviors of components. Unit tests are also the perfect documentation\nfor a bug report on a component maintained by others.\n\n[#tests_as_safety_net][heading Goal: Tests as Safety Net]\n\nWhen we start building a software system, we are able to keep all the\ndetails of the system in our mind because the system is small. As the size\nof the system increases, it becomes harder and harder to keep all the\ndetails of the system in mind as we make modifications. A comprehensive\nsuite of unit tests over the system give us an automated regression test\nthat gives us the confidence of knowing that our changes are not introducing\nany problems elsewhere in the code.\n\n[#do_no_harm][heading Goal: Do No Harm]\n\nAutomated tests should only reduce risk, not introduce risk into the\nsystem. To achieve this, we want to keep all test code separated from\nproduction code. The easiest way to do this is to put the system under\ntest into a library (static or shared) and link the test executable\nagainst the library. We saw this in the tutorial\n[link test.tutorials.hello_test \"Hello, Test!\"], when we separated the\nsystem under test into the =hello= library and the test code into\n=test_hello.cpp=.\n\n[#fully_automated_test][heading Goal: Fully Automated Test]\n\n__test__ supports fully automated tests by allowing us to supply the\ninputs to the system under test in each test case in order to drive\nthe system into the scenario of interest. Test cases should never\nrely on user input, or they will not be fully automated tests that\ncan run unattended.\n\n[#self_checking_test][heading Goal: Self-Checking Test]\n\n__test__ supports self-checking tests through its rich set of\n[link test.reference.assertion assertions]. Each test case supplies the\ninputs to the system under test and validates the behavior of the system\nusing assertions. Self-checking tests report only bad news and good news\nresults in no notifications. The default output from the test runner only\nreports failing tests and a summary of all tests executed. The test\nrunner also returns a non-zero status code when a test fails, allowing\neasy failure of [@http://en.wikipedia.org/wiki/Continuous_integration\ncontinuous integration] builds.\n\n[#repeatable_test][heading Goal: Repeatable Test]\n\nWe should get the same results from automated tests every time we run\nthem, provided the implementation of the system under test has not changed\nbetween runs. In the context of unit testing, this implies that a test\ncase must control all the collaborators that can influence the system.\n\nThe most troublesome collaborators are among the following:\n* current date and time\n* device input\n* file system\n* system services (Windows registry, networking, etc.)\n* C style apis\n\nIn the book \"Working Effectively with Legacy Code\", Michael Feathers\ndescribed a number of techniques for decoupling the system under test\nfrom such troublesome collaborators that can cause unit tests to\nspuriously fail. All the techniques are variations on a theme: introduce\na level of indirection to decouple the system under test from a collaborator.\nC++ offers [@http://en.wikipedia.org/wiki/Template_metaprogramming#Static_polymorphism\nstatic polymorphism] via templates as well as the usual dynamic\npolymorphism via interfaces to decouple a system under test from a\ncollaborator.\n\n[#simple_tests][heading Goal: Simple Tests]\n\nWe keep tests simple by exercising only one scenario for each test case.\nSimple test cases read linearly through the phases of setup, exercise and\nverify. Trying to exercise too much functionality in a single test case\ncan introduce unnecessary complexity into the test.\n\nDuplication between test cases can make tests hard to read by distracting\nus from the steady rhythm of setup, exercise and verify of test cases.\nYou may find it useful to apply the\n[@http://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) rule of\nthree] when writing test cases to decide when to extract duplication into\na fixture.\n\n[#expressive_tests][heading Goal: Expressive Tests]\n\nSometimes low-level setup details get in the way of a test reading\nclearly. This could be the result of a complicated data structure needed\nin order to exercise the system down a particular code path. Similarly,\nthe verification of a result produced by the system under test may involve\na series of assertions that make the test hard to follow. __test__\nprovides fixtures as a way to localize these distracting details by\nextracting setup and assertion methods into the fixture.\n\nOver time we build up a series of methods in the fixture that allow us\nto express domain concepts succinctly and clearly in the tests, making\nthem more expressive of the scenario in the domain. Fixtures can be\ncombined through aggregation or inheritance in order to express combinations\nand hierarchies of domain concepts.\n\n[#separation_of_concerns][heading Goal: Separation of Concerns]\n\nWe keep test code separated from production code with the packaging\nmechanisms provided by C++. Production code is supplied to the test\nexecutable as a library, either static or dynamic. The test code resides\nin separate source files from the production code. The production code\nconsumed by the test code is compiled with the exact same preprocessor\nsettings as the production code to ensure that tests do not influence\nthe production code.\n\nWe keep concerns separated in our tests by testing each concern in its own\ntest case. Each test case exercises a single scenario and our tests\nexercise the responsibilities or classes individually. If we are\npracticing test-driven development, we keep the\n[@http://en.wikipedia.org/wiki/Single_responsibility_principle single\nresponsibility principle] in mind as we are creating the system to satisfy\nthe evolving tests. When our tests start involving more than one concern,\nit can be a sign that our system under test is covering more than one\nresponsibility.\n\n[#robust_test][heading Goal: Robust Test]\n\nTest cases are robust when small changes to the system under test result\nin a small number of test cases failing. If a small change to the system\nresults in many test cases failing, then our tests are not robust. If\nour tests cases do not sufficiently isolate the system under test from its\ncollaborators, then a change to one part of the system can cause tests on\nseemingly unrelated parts of the system to fail. If we have repeated\nassertions in many test cases for the same system under test, then many\ntest cases can fail if that single assertion fails. Each of these\nsituations is a case of overlap between test cases; in the first case,\nthe overlap is between the parts of the production code unrelated to the\nsystem under test that we exercise and in the second case, the overlap is\nbetween test cases on the system under test. \n\n[endsect]\n\n[section:acceptance_tests Acceptance Tests and Unit Tests]\n\nUnit testing helps us to find bugs \"in the small\"; little implementation\ndetails that we got wrong while we were building a function, a method\nor a class. When we test each class as an isolated unit, we can miss\nerrors in the way two classes interact or in the way a whole ensemble\nof classes cooperate in an integrated system.\n\nAn acceptance test is an automated test that exercises our system as an\nintegrated whole and not as a collection of isolated units. In a unit\ntest, we decouple ourselves from the execution environment in order to\ntest a piece of code in isolation. In an acceptance test, we run the\nwhole system and provide controlled inputs to the system. This may\nconsist of prepared input data files, prepared input databases and so-on.\n\nUsing these two forms of automated testing, we can use them as a vise\nto squeeze bugs between the two forms of automated tests. Unit tests\npush from below and acceptance tests push from above.\n\nWhile the facilities in __test__ can be used to create an automated\nacceptance test, the tools are fairly low-level for the kinds of high-level\ncriteria that an acceptance test would use. Acceptance tests are usually\ndefined by the [@http://en.wikipedia.org/wiki/Product_owner#Roles product\nowner] or customer and will describe acceptance criteria in the language\nclosest to the problem domain and farthest away from the details of the\nimplementation.\n\nA better approach for automated acceptance tests would be a tool such as\n[@http://www.fitnesse.org FitNesse] that is designed for automated\nacceptance testing.\n\n[endsect]\n\n[section:testing_file_io Testing File I/O]\n\nA common problem encountered in unit testing is interaction with the\nfile system: scanning directories, creating files, opening files, reading\nfiles, writing files, creating symbolic links and so-on. Interacting\ndirectly with the file system when executing unit tests can lead to\na failure of tests to be [link robust_test robust] or [link repeatable_test\nrepeatable]. We also want our unit tests to be fast; an execution time of\n100 milliseconds is considered a slow unit test. Interacting directly with the file\nsystem can make our unit tests take too long to execute.\n\nThe simplest approach is to wrap file system operations in an interface\nand perform all operations through the interface. Consider the following\nexample of a function that returns a vector of filenames ending in \".txt\"\nin a given directory:\n\n[import system_under_test/scanner/scanner.hpp][text_files_decl]\n\nHow can we unit test =text_files= without relying on the actual contents\nof the file system? We can decouple =text_files= from the file system by\nintroducing an interface:\n\n[text_files_dependency_decl]\n\nWe've used a forward declaration of =directory_scanner= where =text_files=\nis declared. The interface looks like this:\n\n[import system_under_test/scanner/directory_scanner.hpp][directory_scanner]\n\nThe interface =directory_scanner= is used to isolate the free function\n=text_files= from directly interacting with the file system. In the\nunit tests, we use an implementation of =directory_scanner= that senses\nhow =text_files= uses the interface and allows us to control the data\nmade available to =text_files=. The tests can use a hand-crafted\nfake implementation or an implementation from a mock library. The fake\nmight look something like this:\n\n[import examples/file_system.cpp][fake_directory_scanner]\n\nThe tests for =text_files= use the =fake_directory_scanner= to specify\nthe configuration of the file system for the different test cases:\n\n[test_scanner]\n\nIn production code, we use an implementation of =directory_scanner= that\ninteracts directly with the file system using Boost.FileSystem.\n\n[import system_under_test/scanner/filesystem_directory_scanner.hpp][filesystem_directory_scanner]\n\nWe've wrapped just enough of Boost.FileSystem for our needs;\nBoost.FileSystem has a very large surface area and we don't need to put\nan interface around the entire thing, just enough to satisfy the needs\nof =text_files=.\n\nIf we don't want production code to have to worry about supplying an\ninstance of =filesystem_directory_scanner= to =text_files=, we can use\noverloading on =text_files= and use simple delegation to supply the\ndependency:\n\n[import system_under_test/scanner/scanner.cpp][text_files_impl]\n\nSeeing this, you might wonder if we need to unit test the overload we\njust created? Because we are using simple delegation here, there isn't\nsufficient complexity to warrant unit testing. However, we have no unit\ntests for =filesystem_directory_scanner=, which does have control\nstructures. We will want some sort of automated tests around this code\nto verify that it functions properly. We can use\n[link test.guide.acceptance_tests acceptance tests] to verify the system\nas a whole, exercising all the components end-to-end and not just in\nisolation.\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/system_under_test/scanner/scanner.hpp scanner.hpp]\n * [@boost:/libs/test/doc/src/system_under_test/scanner/scanner.cpp scanner.cpp]\n * [@boost:/libs/test/doc/src/system_under_test/scanner/directory_scanner.hpp directory_scanner.hpp]\n * [@boost:/libs/test/doc/src/system_under_test/scanner/filesystem_directory_scanner.hpp filesystem_directory_scanner.hpp]\n* Tests:\n * [@boost:/libs/test/doc/src/examples/file_system.cpp file_system.cpp]\n\n[endsect]\n\n[section Mocking Collaborators]\n\nIn [link test.guide.testing_file_io testing file I/O], we showed an example\nof creating a class =fake_directory_scanner= that acted as a simple test\ndouble for an interface. Such simple fake objects are fine at first, but\nthey're full of boring boiler plate code and after a while it becomes\ntedious to write them by hand.\n\nFor collaborators defined by a pure virtual base class, also known as\nan interface, there are mock object frameworks that alleviate the need to\nwrite the repetitive boiler plate code. One such mock object framework\nthat is designed to work with __test__ is the\n[@http://turtle.sourceforge.net Turtle mock object framework].\n\nHere is an example of the file system tests written using turtle:\n\n[import examples/turtle_mock.cpp]\n[mock_directory_scanner]\n\nDefining the mock object is considerably simpler than writing a fake\nobject by hand. Turtle uses variadic argument macros and template\nbased type deduction to infer the type signature of the methods simply\nfrom the number of arguments each method takes. This alleviates us from\nhaving to repeat all of this information from the interface into the\nimplementation of the test double.\n\nNow we can rewrite our tests to use a mock object configured for each test\ncase:\n\n[test_scanner_with_mocks]\n\nThe tests themselves are largely unchanged and what is different is the\nintention revealing methods we placed in the test fixture.\nMock object frameworks generally provide a rich set\nof methods on the mock object for setting the expectations on the\nnumber of times a method is called, such as =once()=, the expected\narguments to a method, such as =with()=, and the return value of a method,\nsuch as =returns()=.\n\nWith a turtle mock, the expectations are verified when the mock object\nis destroyed. The mock is a member in our fixture and will be destroyed\nat the end of every test case.\n\n[heading Example Source Code]\n* System under test:\n * [@boost:/libs/test/doc/src/system_under_test/scanner/scanner.hpp scanner.hpp]\n * [@boost:/libs/test/doc/src/system_under_test/scanner/scanner.cpp scanner.cpp]\n * [@boost:/libs/test/doc/src/system_under_test/scanner/directory_scanner.hpp directory_scanner.hpp]\n * [@boost:/libs/test/doc/src/system_under_test/scanner/filesystem_directory_scanner.hpp filesystem_directory_scanner.hpp]\n* Tests:\n * [@boost:/libs/test/doc/src/examples/turtle_mock.cpp turtle_mock.cpp]\n\n[endsect]\n\n[section Testing =main=]\n\nIf there is considerable logic in an appliation's =main= function, this\ncan be difficult to unit test. The\n[@http://en.wikipedia.org/wiki/One_definition_rule One Definition Rule]\nprevents us from having the application's =main= and the unit test\nexecutable's =main= in the same executable. Furthermore, even if we\ncould perform some trick to resolve the multiply defined symbol[footnote\nWe could abuse the C++ preprocessor or use object file symbol\nmodification.], we would still need to figure out how to link the test\nexecutable with the application's =main= function to test the code.\n\nWhen it becomes difficult to test code where it is currently, such as\nin the body of =main=, the simplest thing to do is to move the code\nsomewhere else that makes it easy to test. Here is one way to accomplish\nthis:\n\n# rename =main= to =app_main=.\n# move =app_main= to a library.\n# create a simple delegating =main= that calls =app_main=.\n# write tests for =app_main= by linking against the library.\n\nThe delegating =main= looks like this:\n```\nextern int app_main(int argc, char* argv[]);\n\nint main(int argc, char* argv[])\n{\n return app_main(argc, argv);\n}\n```\nIf you don't already have a library for =app_main=, then create one\nand add all the other application code to the library as well. The\nbuild logic for making the executable will consist of compiling a\nsingle source file containing your delegating implementation of =main=\nand linking against a library containing the rest of the application.\nThis will give you a starting point for writing unit tests for anything\nin your application.\n\n[endsect]\n\n[section Testing Protected or Private Members]\n\nWhen testing a large class, you may find yourself wanting to test\nprotected or private members of the class. The best approach is to\ntest those members by testing the public members of the class. If\nusing the public members of a class requires considerable setup in\norder to force execution down a particular path that exercises the\nprotected or private member in question, then you may wish to refactor\nthe code to enhance testability.\n\nThe most expedient technique for protected members is to raise their\nvisibility through derivation. Suppose we have a base class `B` with\na protected member `p` that we wish to test:\n```\nclass B\n{\n// ... other stuff in B\nprotected:\n bool p();\n};\n```\nWe can derive a class `D` in the test code from the class `B` in the\nproduction code that raises the visibility of `p`:\n```\nclass D : public B\n{\n// ... other stuff needed to build a D from a B\npublic:\n using B::p;\n};\n```\nNow we can write a test for `D::p`.\n\nWhile this certainly seems expedient, it's annoying to write these derived\nclasses simply for the purposes of hoisting members into public visibility.\nIt also just feels dirty. We're taking implementation details that are\nsupposed to be hidden from consumers of the class and we're exposing them.\nIf we are not diligent and watchful, this class `D` in the test\nproject that was only intended for testing may find itself showing up in\nthe production code.\n\nMaybe the problem isn't one of visibility but that we simply aren't\nlistening closely enough to the code in the first place. As Herb Sutter\nshows us in [@http://www.gotw.ca/gotw/076.htm Uses and Abuses of Access\nRights], the \"Liar\", the \"Pickpocket\", the \"Cheat\" and the \"Language\nLawyer\" can all find ways to subvert the access protections afforded to\na class.\n\nWhen we are tempted to test non-public methods of a class, it's because we\nfeel that there is sufficient complexity in these non-public methods to\nwarrant testing them. What if that complexity is trying to tell us\nsomething? If our class is so complex, isn't it possible that it's\nviolating the\n[@http://en.wikipedia.org/wiki/Single_responsibility_principle Single\nResponsibility Principle]? Maybe the class is trying to encompass several\nresponsibilities and should be decomposed into two or more classes, each\nwith a single responsibility. We could perform the\n[@http://www.refactoring.com/catalog/extractClass.html Extract Class]\nrefactoring to create two classes with appropriate public interfaces and\nthen write tests against those new public interfaces.\n\nAnother choice is to refactor the original class using the\n[@http://en.wikipedia.org/wiki/Opaque_pointer \"pimpl idiom\"], elevate\nthe visibility to public of all the methods on the implementation class\nand write tests against the implementation class. This has the same\ndownsides as the derive-and-elevate approach and we're still ignoring\nthe whispers of the code.\n\nWhen your code is hard to test, your code is telling you something.\nListen to the code!\n\n[endsect]\n\n[section Manually Registering Test Cases and Suites]\n\n[heading Registering Test Cases]\n\nYou may have an existing body of tests that you wish to register with\n__test__ manually. You can use __boost_test_case__ to register a \nfunction taking no arguments and returning =void= as a test case:\n\n[import examples/manual_registration.cpp][register_function]\n\nYou can use a test case method on a fixture class by registering a\nfunction that creates an instance of the fixture and invokes the test\nmethod. This assures that a fresh fixture is created for each test\ncase, ensuring that each test executes independently of other tests.\n\n[hello_fixture]\n[register_method_function_instance]\n\nYou can register a method on a class as a test case by using Boost.Bind\nto bind the method to a static instance of the class. This can cause\noen test case to influence the execution of another test case because\nthey share the static fixture.\n\n[register_method_static_instance]\n\nA static instance of the class is used so that the instance exists at the\ntime the test case is invoked. Test case invocation happens after\nregistration, so using a local instance in the registration function is\ninsufficient.\n\n[heading Registering Test Suites]\n\nA new test suite is created with the __boost_test_suite__ macro. The\nnew suite must be added to the master test suite to execute its tests.\nAny number of test suites can be added in a hierarchy of suites and\nany test case can be added to any test suite.\n\n[register_test_suite]\n\n[heading Example Source Code]\n\n* System under test:\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.hpp hello.hpp]\n * [@boost:/libs/test/doc/src/system_under_test/hello/hello.cpp hello.cpp]\n* Tests:\n * [@boost:/libs/test/doc/src/examples/manual_registration.cpp manual_registration.cpp]\n\n[endsect]\n\n[endsect]\n"
},
{
"path": "files/test_driven/Boost.Test Documentation Rewrite/libs/test/doc/todo.txt",
"content": "- Document floating-point comparison algorithms\r\n- BOOST_REQUIRE_CLOSE\r\n- BOOST_REQUIRE_CLOSE_FRACTION\r\n- BOOST_REQUIRE_SMALL\r\n- --run_test comma and slash confusion\r\n"
},
{
"path": "files/test_driven/ReadMe.txt",
"content": "Here's how you can work through this workshop following along at\r\nyour computer.\r\n\r\nPrerequisites:\r\n\r\n1. Download and install CMake 2.8\r\n2. Download and unpack boost 1.55 somewhere on your local machine.\r\n You do not need built libraries for this workshop.\r\n3. Download and unpack Turtle 1.2.5 somewhere on your local machine.\r\n Turtle is a header-only library.\r\n\r\nUnderstanding the slides:\r\n\r\nEach slide has a folder icon in the upper right with a number on it\r\nidentifying the snapshot that corresponds to the code on the slide.\r\nMany snapshots are associated with multiple slides as the explanation\r\nproceeds.\r\n\r\nEach slide has an icon in the lower-right corner that indicates if the\r\ncode is currently failing (red X), passing (green check mark) or being\r\nrefactored (green triangular cyclic arrow). The changes being made\r\nin each slide are shown in blue and error messages are shown in yellow.\r\n\r\nBootstrapping your workspace:\r\n\r\n1. Create a directory for your workspace on your local machine.\r\n2. Start by copying the contents of the snapshot directory 0 to your\r\n workspace. Follow along with the slides and edit LocalPaths.txt at\r\n the appropriate time. This is the only file you should need to edit by\r\n hand. Snapshot 0 contains an initial version of this file with a\r\n path that is almost certainly wrong for your machine.\r\n3. As directed in the sldies, run CMake to bootstrap your build.\r\n4. CMake should then automatically regenerate your build every time\r\n CMakeLists.txt or LocalPaths.txt changes when you build the code.\r\n If not, you can re-run the CMake command to regenerate your build\r\n from the CMakeLists.txt and LocalPaths.txt files.\r\n5. As you proceed through the workshop, copy the contents of the numbered\r\n snapshot to your workspace, overwriting all files. LocalPaths.txt,\r\n which contains paths specific to your local machine, is only present\r\n in snapshot 0 and will not be overwritten from other snapshots.\r\n\r\nWorking the hangman game exercise problem:\r\n\r\nUse a CMake build recipe similar to the one used in the slides to get your\r\nbuild going ASAP -- just copy the workspace CMakeLists.txt and\r\nLocalPaths.txt to your exercise workspace and edit appropriately. Consult\r\nthe Boost.Test documentation rewrite included with the presentation and\r\nthe Turtle documentation included in it's distribution for a reference to\r\nassertion macros and more options for the mock object framework.\r\n"
},
{
"path": "files/test_driven/snapshots/00/CMakeLists.txt",
"content": "cmake_minimum_required(VERSION 2.8)\r\nproject(prime_factors CXX)\r\n\r\nadd_library(factors STATIC\r\n factors/factors.cpp factors/factors.h)\r\n\r\ninclude(LocalPaths.txt)\r\n\r\nset(Boost_USE_STATIC_LIBS ON)\r\nset(Boost_USE_MULTITHREADED ON)\r\nset(Boost_USE_STATIC_RUNTIME OFF)\r\nfind_package(Boost 1.55)\r\n\r\nadd_executable(test_factors\r\n test/test_factors.cpp)\r\n\r\nadd_dependencies(test_factors factors)\r\ntarget_include_directories(test_factors PRIVATE ${Boost_INCLUDE_DIRS})\r\ntarget_link_libraries(test_factors factors)\r\nadd_custom_command(TARGET test_factors\r\n POST_BUILD\r\n COMMAND test_factors)\r\n"
},
{
"path": "files/test_driven/snapshots/00/LocalPaths.txt",
"content": "set(BOOST_INCLUDEDIR D:/Code/boost/boost_1_55_0)\r\n"
},
{
"path": "files/test_driven/snapshots/00/factors/factors.cpp",
"content": ""
},
{
"path": "files/test_driven/snapshots/00/factors/factors.h",
"content": ""
},
{
"path": "files/test_driven/snapshots/00/test/test_factors.cpp",
"content": ""
},
{
"path": "files/test_driven/snapshots/01/CMakeLists.txt",
"content": "cmake_minimum_required(VERSION 2.8)\r\nproject(prime_factors CXX)\r\n\r\nadd_library(factors STATIC\r\n factors/factors.cpp factors/factors.h)\r\n\r\ninclude(LocalPaths.txt)\r\n\r\nset(Boost_USE_STATIC_LIBS ON)\r\nset(Boost_USE_MULTITHREADED ON)\r\nset(Boost_USE_STATIC_RUNTIME OFF)\r\nfind_package(Boost 1.55)\r\n\r\nadd_executable(test_factors\r\n test/test_factors.cpp)\r\n\r\nadd_dependencies(test_factors factors)\r\ntarget_include_directories(test_factors PRIVATE ${Boost_INCLUDE_DIRS})\r\ntarget_link_libraries(test_factors factors)\r\nadd_custom_command(TARGET test_factors\r\n POST_BUILD\r\n COMMAND test_factors)\r\n"
},
{
"path": "files/test_driven/snapshots/01/factors/factors.cpp",
"content": ""
},
{
"path": "files/test_driven/snapshots/01/factors/factors.h",
"content": ""
},
{
"path": "files/test_driven/snapshots/01/test/test_factors.cpp",
"content": "#define BOOST_TEST_MAIN\r\n#include \r\n"
},
{
"path": "files/test_driven/snapshots/02/CMakeLists.txt",
"content": "cmake_minimum_required(VERSION 2.8)\r\nproject(prime_factors CXX)\r\n\r\nadd_library(factors STATIC\r\n factors/factors.cpp factors/factors.h)\r\n\r\ninclude(LocalPaths.txt)\r\n\r\nset(Boost_USE_STATIC_LIBS ON)\r\nset(Boost_USE_MULTITHREADED ON)\r\nset(Boost_USE_STATIC_RUNTIME OFF)\r\nfind_package(Boost 1.55)\r\n\r\nadd_executable(test_factors\r\n test/test_factors.cpp)\r\n\r\nadd_dependencies(test_factors factors)\r\ntarget_include_directories(test_factors PRIVATE factors ${Boost_INCLUDE_DIRS})\r\ntarget_link_libraries(test_factors factors)\r\nadd_custom_command(TARGET test_factors\r\n POST_BUILD\r\n COMMAND test_factors)\r\n"
},
{
"path": "files/test_driven/snapshots/02/factors/factors.cpp",
"content": ""
},
{
"path": "files/test_driven/snapshots/02/factors/factors.h",
"content": ""
},
{
"path": "files/test_driven/snapshots/02/test/test_factors.cpp",
"content": "#define BOOST_TEST_MAIN\r\n#include \r\n#include \"factors.h\"\r\n"
},
{
"path": "files/test_driven/snapshots/03/CMakeLists.txt",
"content": "cmake_minimum_required(VERSION 2.8)\r\nproject(prime_factors CXX)\r\n\r\nadd_library(factors STATIC\r\n factors/factors.cpp factors/factors.h)\r\n\r\ninclude(LocalPaths.txt)\r\n\r\nset(Boost_USE_STATIC_LIBS ON)\r\nset(Boost_USE_MULTITHREADED ON)\r\nset(Boost_USE_STATIC_RUNTIME OFF)\r\nfind_package(Boost 1.55)\r\n\r\nadd_executable(test_factors\r\n test/test_factors.cpp)\r\n\r\nadd_dependencies(test_factors factors)\r\ntarget_include_directories(test_factors PRIVATE factors ${Boost_INCLUDE_DIRS})\r\ntarget_link_libraries(test_factors factors)\r\nadd_custom_command(TARGET test_factors\r\n POST_BUILD\r\n COMMAND test_factors)\r\n"
},
{
"path": "files/test_driven/snapshots/03/factors/factors.cpp",
"content": ""
},
{
"path": "files/test_driven/snapshots/03/factors/factors.h",
"content": ""
},
{
"path": "files/test_driven/snapshots/03/test/test_factors.cpp",
"content": "#define BOOST_TEST_MAIN\r\n#include \r\n#include \"factors.h\"\r\n\r\nusing namespace std;\r\n\r\nBOOST_AUTO_TEST_CASE(one_yields_empty)\r\n{\r\n vector expected;\r\n\r\n vector actual = prime_factors(1);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(\r\n expected.begin(), expected.end(),\r\n actual.begin(), actual.end());\r\n}\r\n"
},
{
"path": "files/test_driven/snapshots/04/CMakeLists.txt",
"content": "cmake_minimum_required(VERSION 2.8)\r\nproject(prime_factors CXX)\r\n\r\nadd_library(factors STATIC\r\n factors/factors.cpp factors/factors.h)\r\n\r\ninclude(LocalPaths.txt)\r\n\r\nset(Boost_USE_STATIC_LIBS ON)\r\nset(Boost_USE_MULTITHREADED ON)\r\nset(Boost_USE_STATIC_RUNTIME OFF)\r\nfind_package(Boost 1.55)\r\n\r\nadd_executable(test_factors\r\n test/test_factors.cpp)\r\n\r\nadd_dependencies(test_factors factors)\r\ntarget_include_directories(test_factors PRIVATE factors ${Boost_INCLUDE_DIRS})\r\ntarget_link_libraries(test_factors factors)\r\nadd_custom_command(TARGET test_factors\r\n POST_BUILD\r\n COMMAND test_factors)\r\n"
},
{
"path": "files/test_driven/snapshots/04/factors/factors.cpp",
"content": ""
},
{
"path": "files/test_driven/snapshots/04/factors/factors.h",
"content": "#if !defined(FACTORS_H)\r\n#define FACTORS_H\r\n\r\n#include \r\n\r\nextern std::vector prime_factors(int n);\r\n\r\n#endif\r\n"
},
{
"path": "files/test_driven/snapshots/04/test/test_factors.cpp",
"content": "#define BOOST_TEST_MAIN\r\n#include \r\n#include \"factors.h\"\r\n\r\nusing namespace std;\r\n\r\nBOOST_AUTO_TEST_CASE(one_yields_empty)\r\n{\r\n vector expected;\r\n\r\n vector actual = prime_factors(1);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(\r\n expected.begin(), expected.end(),\r\n actual.begin(), actual.end());\r\n}\r\n"
},
{
"path": "files/test_driven/snapshots/05/CMakeLists.txt",
"content": "cmake_minimum_required(VERSION 2.8)\r\nproject(prime_factors CXX)\r\n\r\nadd_library(factors STATIC\r\n factors/factors.cpp factors/factors.h)\r\n\r\ninclude(LocalPaths.txt)\r\n\r\nset(Boost_USE_STATIC_LIBS ON)\r\nset(Boost_USE_MULTITHREADED ON)\r\nset(Boost_USE_STATIC_RUNTIME OFF)\r\nfind_package(Boost 1.55)\r\n\r\nadd_executable(test_factors\r\n test/test_factors.cpp)\r\n\r\nadd_dependencies(test_factors factors)\r\ntarget_include_directories(test_factors PRIVATE factors ${Boost_INCLUDE_DIRS})\r\ntarget_link_libraries(test_factors factors)\r\nadd_custom_command(TARGET test_factors\r\n POST_BUILD\r\n COMMAND test_factors)\r\n"
},
{
"path": "files/test_driven/snapshots/05/factors/factors.cpp",
"content": "#include \"factors.h\"\r\n#include \r\n\r\nextern std::vector prime_factors(int n)\r\n{\r\n throw std::runtime_error(\"not implemented\");\r\n}\r\n"
},
{
"path": "files/test_driven/snapshots/05/factors/factors.h",
"content": "#if !defined(FACTORS_H)\r\n#define FACTORS_H\r\n\r\n#include \r\n\r\nextern std::vector prime_factors(int n);\r\n\r\n#endif\r\n"
},
{
"path": "files/test_driven/snapshots/05/test/test_factors.cpp",
"content": "#define BOOST_TEST_MAIN\r\n#include \r\n#include \"factors.h\"\r\n\r\nusing namespace std;\r\n\r\nBOOST_AUTO_TEST_CASE(one_yields_empty)\r\n{\r\n vector expected;\r\n\r\n vector actual = prime_factors(1);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(\r\n expected.begin(), expected.end(),\r\n actual.begin(), actual.end());\r\n}\r\n"
},
{
"path": "files/test_driven/snapshots/06/CMakeLists.txt",
"content": "cmake_minimum_required(VERSION 2.8)\r\nproject(prime_factors CXX)\r\n\r\nadd_library(factors STATIC\r\n factors/factors.cpp factors/factors.h)\r\n\r\ninclude(LocalPaths.txt)\r\n\r\nset(Boost_USE_STATIC_LIBS ON)\r\nset(Boost_USE_MULTITHREADED ON)\r\nset(Boost_USE_STATIC_RUNTIME OFF)\r\nfind_package(Boost 1.55)\r\n\r\nadd_executable(test_factors\r\n test/test_factors.cpp)\r\n\r\nadd_dependencies(test_factors factors)\r\ntarget_include_directories(test_factors PRIVATE factors ${Boost_INCLUDE_DIRS})\r\ntarget_link_libraries(test_factors factors)\r\nadd_custom_command(TARGET test_factors\r\n POST_BUILD\r\n COMMAND test_factors)\r\n"
},
{
"path": "files/test_driven/snapshots/06/factors/factors.cpp",
"content": "#include \"factors.h\"\r\n\r\nextern std::vector prime_factors(int n)\r\n{\r\n return std::vector();\r\n}\r\n"
},
{
"path": "files/test_driven/snapshots/06/factors/factors.h",
"content": "#if !defined(FACTORS_H)\r\n#define FACTORS_H\r\n\r\n#include \r\n\r\nextern std::vector prime_factors(int n);\r\n\r\n#endif\r\n"
},
{
"path": "files/test_driven/snapshots/06/test/test_factors.cpp",
"content": "#define BOOST_TEST_MAIN\r\n#include \r\n#include \"factors.h\"\r\n\r\nusing namespace std;\r\n\r\nBOOST_AUTO_TEST_CASE(one_yields_empty)\r\n{\r\n vector expected;\r\n\r\n vector actual = prime_factors(1);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(\r\n expected.begin(), expected.end(),\r\n actual.begin(), actual.end());\r\n}\r\n"
},
{
"path": "files/test_driven/snapshots/07/CMakeLists.txt",
"content": "cmake_minimum_required(VERSION 2.8)\r\nproject(prime_factors CXX)\r\n\r\nadd_library(factors STATIC\r\n factors/factors.cpp factors/factors.h)\r\n\r\ninclude(LocalPaths.txt)\r\n\r\nset(Boost_USE_STATIC_LIBS ON)\r\nset(Boost_USE_MULTITHREADED ON)\r\nset(Boost_USE_STATIC_RUNTIME OFF)\r\nfind_package(Boost 1.55)\r\n\r\nadd_executable(test_factors\r\n test/test_factors.cpp)\r\n\r\nadd_dependencies(test_factors factors)\r\ntarget_include_directories(test_factors PRIVATE factors ${Boost_INCLUDE_DIRS})\r\ntarget_link_libraries(test_factors factors)\r\nadd_custom_command(TARGET test_factors\r\n POST_BUILD\r\n COMMAND test_factors)\r\n"
},
{
"path": "files/test_driven/snapshots/07/factors/factors.cpp",
"content": "#include \"factors.h\"\r\n\r\nextern std::vector prime_factors(int n)\r\n{\r\n return std::vector();\r\n}\r\n"
},
{
"path": "files/test_driven/snapshots/07/factors/factors.h",
"content": "#if !defined(FACTORS_H)\r\n#define FACTORS_H\r\n\r\n#include \r\n\r\nextern std::vector prime_factors(int n);\r\n\r\n#endif\r\n"
},
{
"path": "files/test_driven/snapshots/07/test/test_factors.cpp",
"content": "#define BOOST_TEST_MAIN\r\n#include \r\n#include \"factors.h\"\r\n\r\nusing namespace std;\r\n\r\nBOOST_AUTO_TEST_CASE(one_yields_empty)\r\n{\r\n vector expected;\r\n\r\n vector actual = prime_factors(1);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(\r\n expected.begin(), expected.end(),\r\n actual.begin(), actual.end());\r\n}\r\n\r\nBOOST_AUTO_TEST_CASE(two_yields_2)\r\n{\r\n vector expected;\r\n expected.push_back(2);\r\n\r\n vector actual = prime_factors(2);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(\r\n expected.begin(), expected.end(),\r\n actual.begin(), actual.end());\r\n}\r\n"
},
{
"path": "files/test_driven/snapshots/08/CMakeLists.txt",
"content": "cmake_minimum_required(VERSION 2.8)\r\nproject(prime_factors CXX)\r\n\r\nadd_library(factors STATIC\r\n factors/factors.cpp factors/factors.h)\r\n\r\ninclude(LocalPaths.txt)\r\n\r\nset(Boost_USE_STATIC_LIBS ON)\r\nset(Boost_USE_MULTITHREADED ON)\r\nset(Boost_USE_STATIC_RUNTIME OFF)\r\nfind_package(Boost 1.55)\r\n\r\nadd_executable(test_factors\r\n test/test_factors.cpp)\r\n\r\nadd_dependencies(test_factors factors)\r\ntarget_include_directories(test_factors PRIVATE factors ${Boost_INCLUDE_DIRS})\r\ntarget_link_libraries(test_factors factors)\r\nadd_custom_command(TARGET test_factors\r\n POST_BUILD\r\n COMMAND test_factors)\r\n"
},
{
"path": "files/test_driven/snapshots/08/factors/factors.cpp",
"content": "#include \"factors.h\"\r\n\r\nextern std::vector prime_factors(int n)\r\n{\r\n std::vector primes;\r\n if (n > 1) {\r\n primes.push_back(2);\r\n }\r\n return primes;\r\n}\r\n"
},
{
"path": "files/test_driven/snapshots/08/factors/factors.h",
"content": "#if !defined(FACTORS_H)\r\n#define FACTORS_H\r\n\r\n#include \r\n\r\nextern std::vector prime_factors(int n);\r\n\r\n#endif\r\n"
},
{
"path": "files/test_driven/snapshots/08/test/test_factors.cpp",
"content": "#define BOOST_TEST_MAIN\r\n#include \r\n#include \"factors.h\"\r\n\r\nusing namespace std;\r\n\r\nBOOST_AUTO_TEST_CASE(one_yields_empty)\r\n{\r\n vector expected;\r\n\r\n vector actual = prime_factors(1);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(\r\n expected.begin(), expected.end(),\r\n actual.begin(), actual.end());\r\n}\r\n\r\nBOOST_AUTO_TEST_CASE(two_yields_2)\r\n{\r\n vector expected;\r\n expected.push_back(2);\r\n\r\n vector actual = prime_factors(2);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(\r\n expected.begin(), expected.end(),\r\n actual.begin(), actual.end());\r\n}\r\n"
},
{
"path": "files/test_driven/snapshots/09/CMakeLists.txt",
"content": "cmake_minimum_required(VERSION 2.8)\r\nproject(prime_factors CXX)\r\n\r\nadd_library(factors STATIC\r\n factors/factors.cpp factors/factors.h)\r\n\r\ninclude(LocalPaths.txt)\r\n\r\nset(Boost_USE_STATIC_LIBS ON)\r\nset(Boost_USE_MULTITHREADED ON)\r\nset(Boost_USE_STATIC_RUNTIME OFF)\r\nfind_package(Boost 1.55)\r\n\r\nadd_executable(test_factors\r\n test/test_factors.cpp)\r\n\r\nadd_dependencies(test_factors factors)\r\ntarget_include_directories(test_factors PRIVATE factors ${Boost_INCLUDE_DIRS})\r\ntarget_link_libraries(test_factors factors)\r\nadd_custom_command(TARGET test_factors\r\n POST_BUILD\r\n COMMAND test_factors)\r\n"
},
{
"path": "files/test_driven/snapshots/09/factors/factors.cpp",
"content": "#include \"factors.h\"\r\n\r\nextern std::vector prime_factors(int n)\r\n{\r\n std::vector primes;\r\n if (n > 1) {\r\n primes.push_back(2);\r\n }\r\n return primes;\r\n}\r\n"
},
{
"path": "files/test_driven/snapshots/09/factors/factors.h",
"content": "#if !defined(FACTORS_H)\r\n#define FACTORS_H\r\n\r\n#include \r\n\r\nextern std::vector prime_factors(int n);\r\n\r\n#endif\r\n"
},
{
"path": "files/test_driven/snapshots/09/test/test_factors.cpp",
"content": "#define BOOST_TEST_MAIN\r\n#include \r\n#include \"factors.h\"\r\n\r\nusing namespace std;\r\n\r\nstruct fixture {\r\n vector expected;\r\n vector actual;\r\n};\r\n\r\nBOOST_AUTO_TEST_CASE(one_yields_empty)\r\n{\r\n fixture f;\r\n\r\n f.actual = prime_factors(1);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(\r\n begin(f.expected), end(f.expected),\r\n begin(f.actual), end(f.actual));\r\n}\r\n\r\nBOOST_AUTO_TEST_CASE(two_yields_2)\r\n{\r\n vector expected;\r\n expected.push_back(2);\r\n\r\n vector actual = prime_factors(2);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(\r\n expected.begin(), expected.end(),\r\n actual.begin(), actual.end());\r\n}\r\n"
},
{
"path": "files/test_driven/snapshots/10/CMakeLists.txt",
"content": "cmake_minimum_required(VERSION 2.8)\r\nproject(prime_factors CXX)\r\n\r\nadd_library(factors STATIC\r\n factors/factors.cpp factors/factors.h)\r\n\r\ninclude(LocalPaths.txt)\r\n\r\nset(Boost_USE_STATIC_LIBS ON)\r\nset(Boost_USE_MULTITHREADED ON)\r\nset(Boost_USE_STATIC_RUNTIME OFF)\r\nfind_package(Boost 1.55)\r\n\r\nadd_executable(test_factors\r\n test/test_factors.cpp)\r\n\r\nadd_dependencies(test_factors factors)\r\ntarget_include_directories(test_factors PRIVATE factors ${Boost_INCLUDE_DIRS})\r\ntarget_link_libraries(test_factors factors)\r\nadd_custom_command(TARGET test_factors\r\n POST_BUILD\r\n COMMAND test_factors)\r\n"
},
{
"path": "files/test_driven/snapshots/10/factors/factors.cpp",
"content": "#include \"factors.h\"\r\n\r\nextern std::vector prime_factors(int n)\r\n{\r\n std::vector primes;\r\n if (n > 1) {\r\n primes.push_back(2);\r\n }\r\n return primes;\r\n}\r\n"
},
{
"path": "files/test_driven/snapshots/10/factors/factors.h",
"content": "#if !defined(FACTORS_H)\r\n#define FACTORS_H\r\n\r\n#include \r\n\r\nextern std::vector prime_factors(int n);\r\n\r\n#endif\r\n"
},
{
"path": "files/test_driven/snapshots/10/test/test_factors.cpp",
"content": "#define BOOST_TEST_MAIN\r\n#include \r\n#include \"factors.h\"\r\n\r\nusing namespace std;\r\n\r\nstruct fixture {\r\n vector expected;\r\n vector actual;\r\n void prime_factors(int n) {\r\n actual = ::prime_factors(n);\r\n }\r\n void verify_expected_factors() {\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(\r\n expected.begin(), expected.end(),\r\n actual.begin(), actual.end());\r\n }\r\n};\r\n\r\nBOOST_AUTO_TEST_CASE(one_yields_empty)\r\n{\r\n fixture f;\r\n\r\n f.prime_factors(1);\r\n\r\n f.verify_expected_factors();\r\n}\r\n\r\nBOOST_AUTO_TEST_CASE(two_yields_2)\r\n{\r\n vector expected;\r\n expected.push_back(2);\r\n\r\n vector actual = prime_factors(2);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(\r\n expected.begin(), expected.end(),\r\n actual.begin(), actual.end());\r\n}\r\n"
},
{
"path": "files/test_driven/snapshots/11/CMakeLists.txt",
"content": "cmake_minimum_required(VERSION 2.8)\r\nproject(prime_factors CXX)\r\n\r\nadd_library(factors STATIC\r\n factors/factors.cpp factors/factors.h)\r\n\r\ninclude(LocalPaths.txt)\r\n\r\nset(Boost_USE_STATIC_LIBS ON)\r\nset(Boost_USE_MULTITHREADED ON)\r\nset(Boost_USE_STATIC_RUNTIME OFF)\r\nfind_package(Boost 1.55)\r\n\r\nadd_executable(test_factors\r\n test/test_factors.cpp)\r\n\r\nadd_dependencies(test_factors factors)\r\ntarget_include_directories(test_factors PRIVATE factors ${Boost_INCLUDE_DIRS})\r\ntarget_link_libraries(test_factors factors)\r\nadd_custom_command(TARGET test_factors\r\n POST_BUILD\r\n COMMAND test_factors)\r\n"
},
{
"path": "files/test_driven/snapshots/11/factors/factors.cpp",
"content": "#include \"factors.h\"\r\n\r\nextern std::vector prime_factors(int n)\r\n{\r\n std::vector primes;\r\n if (n > 1) {\r\n primes.push_back(2);\r\n }\r\n return primes;\r\n}\r\n"
},
{
"path": "files/test_driven/snapshots/11/factors/factors.h",
"content": "#if !defined(FACTORS_H)\r\n#define FACTORS_H\r\n\r\n#include \r\n\r\nextern std::vector prime_factors(int n);\r\n\r\n#endif\r\n"
},
{
"path": "files/test_driven/snapshots/11/test/test_factors.cpp",
"content": "#define BOOST_TEST_MAIN\r\n#include \r\n#include \"factors.h\"\r\n\r\nusing namespace std;\r\n\r\nstruct fixture {\r\n vector expected;\r\n vector actual;\r\n void prime_factors(int n) {\r\n actual = ::prime_factors(n);\r\n }\r\n void verify_expected_factors() {\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(\r\n expected.begin(), expected.end(),\r\n actual.begin(), actual.end());\r\n }\r\n};\r\n\r\nBOOST_FIXTURE_TEST_CASE(one_yields_empty, fixture)\r\n{\r\n prime_factors(1);\r\n\r\n verify_expected_factors();\r\n}\r\n\r\nBOOST_AUTO_TEST_CASE(two_yields_2)\r\n{\r\n vector expected;\r\n expected.push_back(2);\r\n\r\n vector actual = prime_factors(2);\r\n\r\n BOOST_REQUIRE_EQUAL_COLLECTIONS(\r\n expected.begin(), expected.end(),\r\n actual.begin(), actual.end());\r\n}\r\n"
},
{
"path": "files/test_driven/snapshots/12/CMakeLists.txt",
"content": "cmake_minimum_required(VERSION 2.8)\r\nproject(prime_factors CXX)\r\n\r\nadd_library(factors STATIC\r\n factors/factors.cpp factors/factors.h)\r\n\r\ninclude(LocalPaths.txt)\r\n\r\nset(Boost_USE_STATIC_LIBS ON)\r\nset(Boost_USE_MULTITHREADED ON)\r\nset(Boost_USE_STATIC_RUNTIME OFF)\r\nfind_package(Boost 1.55)\r\n\r\nadd_executable(test_factors\r\n test/test_factors.cpp)\r\n\r\nadd_dependencies(test_factors factors)\r\ntarget_include_directories(test_factors PRIVATE factors ${Boost_INCLUDE_DIRS})\r\ntarget_link_libraries(test_factors factors)\r\nadd_custom_command(TARGET test_factors\r\n POST_BUILD\r\n COMMAND test_factors)\r\n"
},
{
"path": "files/test_driven/snapshots/12/factors/factors.cpp",
"content": "#include \"factors.h\"\r\n\r\nextern std::vector
![\"Boost](\"../../../../boost.png\")
![\"Next\"](\"../../../../doc/src/images/next.png\")
![\"Boost](\"../../../../../../boost.png\")
![\"Prev\"](\"../../../../../../doc/src/images/prev.png\")
![\"Up\"](\"../../../../../../doc/src/images/up.png\")
![\"Home\"](\"../../../../../../doc/src/images/home.png\")
![\"Next\"](\"../../../../../../doc/src/images/next.png\")
\n![\"Boost](\"../../../../../../../boost.png\")
![\"Prev\"](\"../../../../../../../doc/src/images/prev.png\")
![\"Up\"](\"../../../../../../../doc/src/images/up.png\")
![\"Home\"](\"../../../../../../../doc/src/images/home.png\")
![\"Next\"](\"../../../../../../../doc/src/images/next.png\")
\n![\"[Caution]\"](\"../../../../../../doc/src/images/caution.png\")
![\"user-vs2012-build-event\"](\"../../../src/user-vs2012-build-event.png\")
\n ![\"Boost](\"../../../../../boost.png\")
![\"Prev\"](\"../../../../../doc/src/images/prev.png\")
![\"Up\"](\"../../../../../doc/src/images/up.png\")
![\"Home\"](\"../../../../../doc/src/images/home.png\")
![\"Next\"](\"../../../../../doc/src/images/next.png\")
\n![\"[Important]\"](\"../../../../../../../doc/src/images/important.png\")
![\"[Important]\"](\"../../../../../../doc/src/images/important.png\")
![\"Boost](\"../../../../../../../../boost.png\")
![\"Prev\"](\"../../../../../../../../doc/src/images/prev.png\")
![\"Up\"](\"../../../../../../../../doc/src/images/up.png\")
![\"Home\"](\"../../../../../../../../doc/src/images/home.png\")
![\"Next\"](\"../../../../../../../../doc/src/images/next.png\")
\n![\"[Note]\"](\"../../../../../../../doc/src/images/note.png\")
![\"[Important]\"](\"../../../../../../../../doc/src/images/important.png\")
![\"[Note]\"](\"../../../../../../doc/src/images/note.png\")