12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152 |
- [/
- / Copyright (c) 2003 Boost.Test contributors
- /
- / Distributed under the Boost Software License, Version 1.0. (See accompanying
- / file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
- /]
- [/ ##################################################################### ]
- [section:adv_scenarios Advanced Usage Scenarios]
- If you are reading this chapter, this means that the wide range of tools and interfaces covered
- in the previous sections are not sufficient for the testing scenario
- you have in mind. You are here to bend the __UTF__ to your will and ... we are not going to
- stop you. Instead we'll try to guide you so that some dark corners do not look scary.
- In most cases the __UTF__ is going to be supplied for you either as part of your system libraries
- or set of libraries used by your companies. Yet if you are facing the necessity to build your
- own static or dynamic library of the __UTF__ or need to customize the build for any reason, section
- [link boost_test.adv_scenarios.build_utf Building the __UTF__] covers all the necessary steps.
- To streamline the experience of setting up your test module, the __UTF__ provides some default
- initialization logic for them. Usually the default test module initialization will work just fine,
- but if you want to implement some custom initialization or change how default initialization
- behaves you need to first look in [*Test module initialization] section. Here you'll learn
- about various options the __UTF__ provides for you to customize this behavior.
- The part of the framework which loads, initializes and executed your test module is called the
- [*Test Runner]. Each usage variant comes with default test runner. If, instead, you prefer to
- implement your own entry point into the test module (for example if you need to implement the
- `main` function yourself and not use the one provided by the __UTF__, you need to learn about
- __UTF__ interfaces involved in test runners operations. These are covered in the [*Test runners]
- section. Let me reiterate that you only need to this section if regular regular options for
- customization of initialization logic like
- [link boost_test.tests_organization.fixtures fixtures] or [link boost_test.tests_organization.decorators decorators]
- are not sufficient for your purposes.
- [/ build and link with boost.test]
- [include adv_scenarios/building_utf.qbk]
- [include adv_scenarios/entry_point_overview.qbk]
- [include adv_scenarios/test_module_init_overview.qbk]
- [include adv_scenarios/test_module_runner_overview.qbk]
- [include adv_scenarios/single_header_customizations.qbk]
- [include adv_scenarios/static_lib_customizations.qbk]
- [include adv_scenarios/shared_lib_customizations.qbk]
- [include adv_scenarios/external_test_runner.qbk]
- [include adv_scenarios/obsolete_init_func.qbk]
- [/=============================================================================]
- [endsect] [/Advanced usage scenarios]
- [/ EOF]
|