* topic/5563-test-macros-in-global-fixtures:
Change logs
Documentation update for the new macros
Fixing logging issues for JUnit with global fixtures
Fixture setup/teardown now applied to BOOST_FIXTURE_TEST_CASE familly of macros
Fixture setup/teardown detection for C++11 capable compilers
Improving global initialization and fixtures
- BOOST_TEST_GLOBAL_FIXTURE explained
- BOOST_TEST_GLOBAL_INITIALIZATION explained
- changed the examples, deprecating BOOST_GLOBAL_FIXTURE
- in the logger part, introduced the fact that BOOST_TEST_GLOBAL_INITIALIZATION should be used and no assertion is supported in this case
- considering skipped tests: a skipped test is not considered as an error, especially when there was no logged information
- removing CR/LF from TU names
- updating the JUnit output
- additional refactoring of junit
- new macros:
BOOST_TEST_GLOBAL_FIXTURE: for global "real" fixtures
BOOST_TEST_GLOBAL_CONFIGURATION: for global configuration of observers.
- deprecating BOOST_GLOBAL_FIXTURE. BOOST_GLOBAL_FIXTURE and BOOST_TEST_GLOBAL_CONFIGURATION are currently
fully equivalent, the former being confusing in term of scope/role is deprecated
- SFINAE detection for a setup/teardown function within the fixture class
- Attaching global fixture to the main or master test unit being executed, exactly as other fixtures. Global fixtures
via BOOST_TEST_GLOBAL_FIXTURE registers themselves in a particular field of the framework and are attached each time
the framework executes the tests, such that we can run the framework on another test root and still benefit from the
global fixtures. The global fixtures are appended to already existing fixtures (in case the master test suite is not
the root of the current execution tree).
- Checking that the framework setup is not failing for running the test
- RAII class for restoring the global fixtures
- Tests on the setup/teardown detection
- Tests on global fixtures and baseline
- Fixing several logging issues
Some additional refactoring
- renaming m_curr_test_case to m_curr_test_unit
- function for providing the current test unit (and not only the current test case)
- for output_stream comparison: stops properly if the reference stream is shorter than the current one,
initialises the read char correctly to 0 and prints a proper ~ at the mismatch location
* topic/PR106-VS2017-C++17-compatibility:
Change log
Conditionally replace deprecated/removed C++98 binders, adapters, and random_shuffle by emulations using more modern equivalents.
* topic/11756-non-standards-fpexception-intel:
Changelog
FPE: disabling support of the glibC extensions for uLibC std library
Preventing the compilation of floating points with GCC when glibc is not in use
- Gathering the support of FPE in one place/several macros and using those in both
execution_monitor.hpp and execution_monitor.ipp in a more coherent way
- Updating the support of the floating point exceptions: fenableexcept/fdisableexcept are
GLIBC extensions and the definition of FENV does not imply the existance of those functions
* topic/12540-printing-types-customisation-point:
Change log update
Documenting the customization point
Fixing the tests and checking everything works ok
Test for customization points
Customization points for printing user defined types through `boost_test_print_type`
* topic/junit-more-efficient:
Change log update
JUnit: updating documentation
JUnit: changing the default to log-messages
JUnit: refactoring for handling the different phases in an easier way
JUnit: being able to indicate the log level for speeding up
Using lists for the output streams
Lowering JUnit output memory footprint
- junit internal log level to be able to intercept all the intermediate messages (tu enter/exit)
- skipping events that do not match the desired log level
- some refactoring (root of the subtree, getter of the current log)
- logs that do not belong to any TU go to a global log
TODO: global log should be outputted to the stream as well
* topic/12712-several-test-suite-decl-in-same-comp-unit:
Change log
Fix using __COUNTER__ when available
Test case firing issue 12712
Correction of the previous syntax fix
Fix Markdown link format
Preparing changelog for 1.64
The scenario is that we have two identical files defining test cases and suites. The suites are the same in both files, tests are not. The line numbers are the same as well.
Finally those files are #include'd in a unique .cpp file. The registrar for the test suites are having the same name and raising a compilation error
I messed up the order of the different brackets and did not preview the
markdown before pushing. I'm very sorry.
This fix is tested in Atom's Markdown preview now and really fixes the
issue.
