version 2.0.0
diff --git a/doc/html_generated/assertions.html b/doc/html_generated/assertions.html
index 12db9a6..1460823 100644
--- a/doc/html_generated/assertions.html
+++ b/doc/html_generated/assertions.html
@@ -19,6 +19,8 @@
All asserts evaluate the expressions only once and if they fail - the values are [**stringified**](stringification.html) properly.
+Since **doctest** is [**thread-safe**](faq.html#is-doctest-thread-aware) all asserts and [**logging**](logging.html) macros can be used in threads spawned from test cases.
+
Note that the ```REQUIRE``` level of asserts uses exceptions to end the current test case. It might be dangerous to use this level of asserts inside destructors of user-defined classes - if a destructor is called during stack unwinding due to an exception and a ```REQUIRE``` assert fails then the program will terminate. Also since C++11 all destructors are by default ```noexcept(true)``` unless specified otherwise so such an assert will lead to ```std::terminate()``` being called.
## Expression decomposing asserts
@@ -121,6 +123,18 @@
Note that these asserts also have a ```_MESSAGE``` form - like ```CHECK_THROWS_MESSAGE(expression, message)``` - these work identically to the ```_MESSAGE``` form of the normal macros (```CHECK_MESSAGE(a < b, "this shouldn't fail")```) described earlier.
+## Using asserts out of a testing context
+
+Asserts can be used outside of a testing context (in code not called from a ```TEST_CASE()```) instead of [```assert()```](https://en.cppreference.com/w/cpp/error/assert).
+
+A ```doctest::Context``` object still has to be created somewhere and set as the default one using the ```setAsDefaultForAssertsOutOfTestCases()``` method - and then asserts will work. A handler can be registered by calling the ```setAssertHandler()``` method on the context object. If no handler is set then ```std::abort()``` is called on failure.
+
+The results would be best when using the [**fast asserts**](assertions.html#fast-asserts) coupled with the [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) config identifier and by defining your own macro aliases - like shown [**here**](../../examples/all_features/doctest_proxy.h).
+
+Checkout the [**example**](../../examples/all_features/asserts_used_outside_of_tests.cpp) showcasing how that is done. For more information see the [**issue for the feature request**](https://github.com/onqtam/doctest/issues/114).
+
+Currently [**logging macros**](logging.html) cannot be used for extra context for asserts outside of a test run. That means that the ```_MESSAGE``` variants of asserts are also not usable - since they are just a packed ```INFO()``` with an assert right after it.
+
## Floating point comparisons
When comparing floating point numbers - especially if at least one of them has been computed - great care must be taken to allow for rounding errors and inexact representations.
@@ -148,6 +162,8 @@
[Home](readme.html#reference)
+<p align="center"><img src="../../scripts/data/logo/icon_2.svg"></p>
+
</xmp>
<script src="strapdown.js/strapdown.js"></script>
diff --git a/doc/html_generated/benchmarks.html b/doc/html_generated/benchmarks.html
index 038c20c..3dd49fd 100644
--- a/doc/html_generated/benchmarks.html
+++ b/doc/html_generated/benchmarks.html
@@ -13,8 +13,8 @@
Compilers used:
-- WINDOWS: Microsoft Visual Studio Community 2017 - Version 15.3.3+26730.12
-- WINDOWS: gcc 7.1.0 (x86_64-posix-seh-rev2, Built by MinGW-W64 project)
+- WINDOWS: Microsoft Visual Studio Community 2017 - Version 15.8.1+28010.2003
+- WINDOWS: gcc 8.1.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)
- LINUX: gcc 6.3.0 20170406 (Ubuntu 6.3.0-12ubuntu2)
- LINUX: clang 4.0.0-1 (tags/RELEASE_400/rc1) Target: x86_64-pc-linux-gnu
@@ -23,9 +23,9 @@
- Windows 7 - on an SSD
- Ubuntu 17.04 in a VirtualBox VM - on a HDD
-**doctest** version: 1.2.2 (released on 2017.09.05)
+**doctest** version: 2.0.0 (released on 2018.08.23)
-[**Catch**](https://github.com/philsquared/Catch) version: 2.0.0-develop.3 (released on 2017.08.30)
+[**Catch**](https://github.com/philsquared/Catch) version: 2.3.0 (released on 2018.07.22)
# Compile time benchmarks
@@ -47,25 +47,25 @@
| doctest | baseline | + implement | + header everywhere | + disabled |
|---------------------|----------|-------------|---------------------|------------|
-| MSVC Debug | 6.77 | 8.28 | 11.73 | 8.73 |
-| MSVC Release | 6.35 | 8.57 | 12.18 | 8.28 |
-| MinGW GCC Debug | 10.23 | 13.03 | 17.62 | 12.29 |
-| MinGW GCC Release | 10.33 | 13.68 | 17.87 | 13.11 |
-| Linux GCC Debug | 5.01 | 6.24 | 10.48 | 6.49 |
-| Linux GCC Release | 4.58 | 7.30 | 11.70 | 7.41 |
-| Linux Clang Debug | 8.80 | 9.70 | 14.92 | 10.89 |
-| Linux Clang Release | 9.29 | 12.05 | 17.51 | 11.56 |
+| MSVC Debug | 4.89 | 6.21 | 8.33 | 6.39 |
+| MSVC Release | 4.38 | 6.39 | 8.71 | 6.02 |
+| MinGW GCC Debug | 8.12 | 10.86 | 14.73 | 10.17 |
+| MinGW GCC Release | 8.21 | 11.11 | 15.03 | 10.71 |
+| Linux GCC Debug | 4.20 | 6.23 | 9.81 | 6.24 |
+| Linux GCC Release | 4.29 | 6.93 | 11.05 | 6.76 |
+| Linux Clang Debug | 8.70 | 10.02 | 14.43 | 11.13 |
+| Linux Clang Release | 9.30 | 11.68 | 16.20 | 11.58 |
| Catch | baseline | + implement | + header everywhere | + disabled |
|---------------------|----------|-------------|---------------------|------------|
-| MSVC Debug | 6.78 | 10.00 | 107.85 | 115.05 |
-| MSVC Release | 6.36 | 11.19 | 102.69 | 109.06 |
-| MinGW GCC Debug | 10.36 | 41.83 | 124.41 | 126.70 |
-| MinGW GCC Release | 10.49 | 21.93 | 97.81 | 105.47 |
-| Linux GCC Debug | 4.40 | 12.39 | 94.34 | 93.68 |
-| Linux GCC Release | 4.55 | 15.75 | 94.28 | 93.80 |
-| Linux Clang Debug | 9.30 | 15.00 | 105.84 | 103.05 |
-| Linux Clang Release | 9.68 | 22.75 | 114.36 | 111.32 |
+| MSVC Debug | 4.82 | 7.83 | 88.85 | 88.72 |
+| MSVC Release | 4.38 | 9.97 | 87.17 | 88.35 |
+| MinGW GCC Debug | 8.00 | 57.28 | 137.28 | 132.73 |
+| MinGW GCC Release | 8.38 | 22.94 | 97.17 | 97.22 |
+| Linux GCC Debug | 4.42 | 15.57 | 97.94 | 97.18 |
+| Linux GCC Release | 4.50 | 19.59 | 99.48 | 100.75 |
+| Linux Clang Debug | 8.76 | 15.60 | 107.99 | 110.61 |
+| Linux Clang Release | 9.32 | 25.75 | 118.67 | 117.11 |
<img src="../../scripts/data/benchmarks/header.png" width="430" align="right">
<img src="../../scripts/data/benchmarks/implement.png" width="430">
@@ -75,18 +75,18 @@
#### doctest
- instantiating the test runner in one source file costs ~1-3 seconds ```implement - baseline```
-- the inclusion of ```doctest.h``` in one source file costs between 17ms - 27ms ```(header_everywhere - implement) / 200```
+- the inclusion of ```doctest.h``` in one source file costs between 11ms - 23ms ```(header_everywhere - implement) / 200```
- including the library everywhere but everything disabled costs around 2 seconds ```disabled - baseline``` for 200 files
#### [Catch](https://github.com/philsquared/Catch)
-- instantiating the test runner in one source file costs ~4-31 seconds ```implement - baseline```
-- the inclusion of ```catch.hpp``` in one source file costs between 390ms - 490ms ```(header_everywhere - implement) / 200```
+- instantiating the test runner in one source file costs ~3-50 seconds ```implement - baseline```
+- the inclusion of ```catch.hpp``` in one source file costs between 380ms - 470ms ```(header_everywhere - implement) / 200```
- using the config option to disable the library (**```CATCH_CONFIG_DISABLE```**) has no effect on the header cost
----------
-So if ```doctest.h``` costs 17ms and ```catch.hpp``` costs 490ms on MSVC - then the **doctest** header is >> **27** << times lighter (for MSVC)!
+So if ```doctest.h``` costs 11ms and ```catch.hpp``` costs 400ms on MSVC - then the **doctest** header is >> **36** << times lighter (for MSVC)!
----------
@@ -115,27 +115,27 @@
| doctest | baseline | ```CHECK(a==b)``` | ```CHECK_EQ(a,b)``` | ```FAST_CHECK_EQ(a,b)``` | +faster | +disabled |
|---------------------|----------|-------------------|---------------------|--------------------------|---------|-----------|
-| MSVC Debug | 3.08 | 23.72 | 18.15 | 8.38 | 5.67 | 2.23 |
-| MSVC Release | 3.61 | 43.75 | 24.28 | 11.36 | 7.22 | 2.15 |
-| MinGW GCC Debug | 3.90 | 85.47 | 58.62 | 24.40 | 12.12 | 1.71 |
-| MinGW GCC Release | 4.51 | 224.49 | 148.84 | 47.25 | 18.73 | 2.40 |
-| Linux GCC Debug | 2.01 | 78.38 | 50.61 | 17.62 | 9.87 | 1.11 |
-| Linux GCC Release | 3.20 | 199.78 | 123.42 | 32.47 | 19.52 | 1.97 |
-| Linux Clang Debug | 1.71 | 77.39 | 49.97 | 17.60 | 7.57 | 1.18 |
-| Linux Clang Release | 3.64 | 136.82 | 80.19 | 20.72 | 12.34 | 1.45 |
+| MSVC Debug | 2.60 | 26.47 | 16.66 | 7.27 | 4.85 | 1.95 |
+| MSVC Release | 3.02 | 58.13 | 25.66 | 10.37 | 6.29 | 1.74 |
+| MinGW GCC Debug | 3.65 | 93.97 | 58.46 | 23.82 | 11.41 | 1.60 |
+| MinGW GCC Release | 3.92 | 276.09 | 150.53 | 48.41 | 17.48 | 1.96 |
+| Linux GCC Debug | 2.34 | 92.38 | 53.10 | 17.95 | 9.76 | 1.21 |
+| Linux GCC Release | 3.05 | 249.08 | 122.91 | 31.90 | 19.44 | 1.76 |
+| Linux Clang Debug | 2.33 | 82.15 | 49.46 | 18.46 | 8.26 | 1.47 |
+| Linux Clang Release | 3.10 | 151.88 | 76.89 | 20.47 | 11.53 | 1.73 |
And here is [**Catch**](https://github.com/philsquared/Catch) which only has normal ```CHECK(a==b)``` asserts:
| Catch | baseline | ```CHECK(a==b)``` | +faster | +disabled |
|---------------------|----------|-------------------|---------|-----------|
-| MSVC Debug | 9.58 | 37.69 | 25.21 | 10.40 |
-| MSVC Release | 10.85 | 260.55 | 121.38 | 11.56 |
-| MinGW GCC Debug | 36.24 | 159.15 | 133.98 | 33.57 |
-| MinGW GCC Release | 16.15 | 740.71 | 562.60 | 16.41 |
-| Linux GCC Debug | 12.71 | 142.92 | 108.07 | 12.05 |
-| Linux GCC Release | 15.62 | 825.42 | 612.06 | 15.51 |
-| Linux Clang Debug | 10.48 | 115.19 | 89.59 | 10.78 |
-| Linux Clang Release | 18.25 | 393.31 | 316.98 | 17.19 |
+| MSVC Debug | 8.20 | 31.22 | 25.54 | 8.22 |
+| MSVC Release | 10.13 | 448.68 | 168.67 | 10.20 |
+| MinGW GCC Debug | 53.54 | 152.38 | 131.85 | 49.07 |
+| MinGW GCC Release | 19.26 | 590.16 | 466.69 | 18.99 |
+| Linux GCC Debug | 15.05 | 117.30 | 95.33 | 14.79 |
+| Linux GCC Release | 18.77 | 608.94 | 482.73 | 18.96 |
+| Linux Clang Debug | 12.27 | 94.39 | 77.33 | 12.11 |
+| Linux Clang Release | 20.75 | 545.84 | 506.02 | 20.15 |
<img src="../../scripts/data/benchmarks/asserts.png">
@@ -143,16 +143,16 @@
**doctest**:
-- is around 30% to 75% faster than [**Catch**](https://github.com/philsquared/Catch) when using normal expression decomposing ```CHECK(a==b)``` asserts
-- asserts of the form ```CHECK_EQ(a,b)``` with no expression decomposition - around 25%-45% faster than ```CHECK(a==b)```
-- fast asserts like ```FAST_CHECK_EQ(a,b)``` with no ```try/catch``` blocks - around 60-80% faster than ```CHECK_EQ(a,b)```
-- the [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) identifier which makes the fast assertions even faster by another 50-80%
-- using the [**```DOCTEST_CONFIG_DISABLE```**](configuration.html#doctest_config_disable) identifier the assertions just disappear as if they were never written
+- is between 0 and 8 times faster than [**Catch**](https://github.com/philsquared/Catch) when using normal expression decomposing ```CHECK(a==b)``` asserts
+- asserts of the form ```CHECK_EQ(a,b)``` with no expression decomposition - around 31%-63% faster than ```CHECK(a==b)```
+- fast asserts like ```FAST_CHECK_EQ(a,b)``` with no ```try/catch``` blocks - around 64-86% faster than ```CHECK_EQ(a,b)```
+- the [**```DOCTEST_CONFIG_SUPER_FAST_ASSERTS```**](configuration.html#doctest_config_super_fast_asserts) identifier which makes the fast assertions even faster by another 55-78%
+- using the [**```DOCTEST_CONFIG_DISABLE```**](configuration.html#doctest_config_disable) identifier the assertions just disappear as if they were never written - even lower than the baseline (because most of the implementation is also gone)
[**Catch**](https://github.com/philsquared/Catch):
-- using [**```CATCH_CONFIG_FAST_COMPILE```**](https://github.com/philsquared/Catch/blob/master/docs/configuration.html#catch_config_fast_compile) results in 15%-55% faster build times for asserts.
-- using the **```CATCH_CONFIG_DISABLE```** identifier provides the same great benefits for assertion macros as the doctest version ([**```DOCTEST_CONFIG_DISABLE```**](configuration.html#doctest_config_disable)) - unlike the case for the header cost
+- using [**```CATCH_CONFIG_FAST_COMPILE```**](https://github.com/philsquared/Catch/blob/master/docs/configuration.html#catch_config_fast_compile) results in 10%-30% faster build times for asserts (and in one case 73%).
+- using the **```CATCH_CONFIG_DISABLE```** identifier provides the same great benefits for assertion macros as the doctest version ([**```DOCTEST_CONFIG_DISABLE```**](configuration.html#doctest_config_disable)) - unlike in the case for the header cost
## Runtime benchmarks
@@ -176,23 +176,21 @@
| doctest | assert | + info | | Catch | assert | + info |
|---------------------|---------|---------|-|---------------------|---------|---------|
-| MSVC Debug | 5.04 | 13.03 | | MSVC Debug | 101.07 | 338.41 |
-| MSVC Release | 0.73 | 1.67 | | MSVC Release | 1.75 | 10.99 |
-| MinGW GCC Debug | 2.11 | 4.50 | | MinGW GCC Debug | 4.76 | 18.22 |
-| MinGW GCC Release | 0.36 | 0.86 | | MinGW GCC Release | 1.24 | 7.29 |
-| Linux GCC Debug | 2.49 | 4.97 | | Linux GCC Debug | 5.41 | 19.01 |
-| Linux GCC Release | 0.29 | 0.66 | | Linux GCC Release | 1.20 | 7.88 |
-| Linux Clang Debug | 2.39 | 4.76 | | Linux Clang Debug | 5.12 | 17.66 |
-| Linux Clang Release | 0.39 | 0.70 | | Linux Clang Release | 0.99 | 7.26 |
+| MSVC Debug | 4.00 | 11.41 | | MSVC Debug | 5.60 | 213.91 |
+| MSVC Release | 0.40 | 1.47 | | MSVC Release | 0.76 | 7.60 |
+| MinGW GCC Debug | 1.05 | 2.93 | | MinGW GCC Debug | 1.17 | 9.54 |
+| MinGW GCC Release | 0.34 | 1.27 | | MinGW GCC Release | 0.36 | 4.28 |
+| Linux GCC Debug | 1.24 | 2.34 | | Linux GCC Debug | 1.44 | 9.69 |
+| Linux GCC Release | 0.29 | 0.52 | | Linux GCC Release | 0.29 | 3.60 |
+| Linux Clang Debug | 1.15 | 2.38 | | Linux Clang Debug | 1.21 | 9.91 |
+| Linux Clang Release | 0.28 | 0.50 | | Linux Clang Release | 0.32 | 3.27 |
<img src="../../scripts/data/benchmarks/runtime_info.png" width="430" align="right">
<img src="../../scripts/data/benchmarks/runtime_assert.png" width="430">
### Conclusion
-**doctest** is significantly faster - between 2.5 and 26 times.
-
-In these particular cases **doctest** makes 0 allocations when the assert doesn't fail - it uses lazy stringification (meaning it stringifies the expression or the logged loop counter only if it has to) and a small-buffer optimized string class to achieve these results.
+**doctest** is around ~20% faster than catch for asserts but a few times faster when also logging variables and context (and in the case of one particular compiler over 18 times faster).
----------
@@ -206,6 +204,8 @@
[Home](readme.html#reference)
+<p align="center"><img src="../../scripts/data/logo/icon_2.svg"></p>
+
</xmp>
<script src="strapdown.js/strapdown.js"></script>
diff --git a/doc/html_generated/build-systems.html b/doc/html_generated/build-systems.html
index fe12a8e..6c9b778 100644
--- a/doc/html_generated/build-systems.html
+++ b/doc/html_generated/build-systems.html
@@ -7,7 +7,7 @@
The latest released version of doctest can be obtained from here: https://raw.githubusercontent.com/onqtam/doctest/master/doctest/doctest.h
-You can substitute ```master``` with ```dev``` or a tag like ```1.2.0``` for a specific version in the URL above.
+You can substitute ```master``` with ```dev``` or a tag like ```1.2.9``` for a specific version in the URL above.
### CMake
@@ -82,6 +82,8 @@
[Home](readme.html#reference)
+<p align="center"><img src="../../scripts/data/logo/icon_2.svg"></p>
+
</xmp>
<script src="strapdown.js/strapdown.js"></script>
diff --git a/doc/html_generated/commandline.html b/doc/html_generated/commandline.html
index 82715b5..688d0a9 100644
--- a/doc/html_generated/commandline.html
+++ b/doc/html_generated/commandline.html
@@ -25,6 +25,7 @@
| ```-c``` ```--count``` | Prints the number of test cases matching the current filters (see below) |
| ```-ltc``` ```--list-test-cases``` | Lists all test cases by name which match the current filters (see below) |
| ```-lts``` ```--list-test-suites``` | Lists all test suites by name which have at least one test case matching the current filters (see below) |
+| ```-lr``` ```--list-reporters``` | Lists all registered [**reporters**](reporters.html) |
| **Int/String Options** | <hr> |
| ```-tc``` ```--test-case=<filters>``` | Filters test cases based on their name. By default all test cases match but if a value is given to this filter like ```--test-case=*math*,*sound*``` then only test cases who match atleast one of the patterns in the comma-separated list with wildcards will get executed/counted/listed |
| ```-tce``` ```--test-case-exclude=<filters>``` | Same as the ```-test-case=<filters>``` option but if any of the patterns in the comma-separated list of values matches - then the test case is skipped |
@@ -34,6 +35,7 @@
| ```-tse``` ```--test-suite-exclude=<filters>``` | Same as ```--test-case-exclude=<filters>``` but filters based on the test suite in which test cases are in |
| ```-sc``` ```--subcase=<filters>``` | Same as ```--test-case=<filters>``` but filters subcases based on their names |
| ```-sce``` ```--subcase-exclude=<filters>``` | Same as ```--test-case-exclude=<filters>``` but filters based on subcase names |
+| ```-r``` ```--reporters=<filters>``` | List of [**reporters**](reporters.html) to use (default is ```console```) |
| ```-ob``` ```--order-by=<string>``` | Test cases will be sorted before being executed either by **the file in which they are** / **the test suite they are in** / **their name** / **random**. The possible values of ```<string>``` are ```file```/```suite```/```name```/```rand```. The default is ```file``` |
| ```-rs``` ```--rand-seed=<int>``` | The seed for random ordering |
| ```-f``` ```--first=<int>``` | The **first** test case to execute which passes the current filters - for range-based execution - see [**the example python script**](../../examples/range_based_execution.py) |
@@ -64,7 +66,7 @@
This is done for easy interoperability with client command line option handling when the testing framework is integrated within a client codebase - all **doctest** related flags/options can be prefixed so there are no clashes and so that the user can exclude everything starting with ```--dt-``` from their option parsing.
-If there isn't an option to exclude everything starting with ```--dt-``` then the ```dt_removed``` helper class might help to filter them out:
+If there isn't an option to exclude those starting with ```--dt-``` then the ```dt_removed``` helper class might help to filter them out:
```
#define DOCTEST_CONFIG_NO_UNPREFIXED_OPTIONS
@@ -126,6 +128,8 @@
[Home](readme.html#reference)
+<p align="center"><img src="../../scripts/data/logo/icon_2.svg"></p>
+
</xmp>
<script src="strapdown.js/strapdown.js"></script>
diff --git a/doc/html_generated/configuration.html b/doc/html_generated/configuration.html
index 3d3c86b..a6ab2bd 100644
--- a/doc/html_generated/configuration.html
+++ b/doc/html_generated/configuration.html
@@ -35,21 +35,6 @@
- [**```DOCTEST_CONFIG_NO_POSIX_SIGNALS```**](#doctest_config_no_posix_signals)
- [**```DOCTEST_CONFIG_INCLUDE_TYPE_TRAITS```**](#doctest_config_include_type_traits)
-Detection of modern C++ features:
-
-- [**```DOCTEST_CONFIG_WITH_DELETED_FUNCTIONS```**](#doctest_config_with_deleted_functions)
-- [**```DOCTEST_CONFIG_WITH_RVALUE_REFERENCES```**](#doctest_config_with_rvalue_references)
-- [**```DOCTEST_CONFIG_WITH_VARIADIC_MACROS```**](#doctest_config_with_variadic_macros)
-- [**```DOCTEST_CONFIG_WITH_NULLPTR```**](#doctest_config_with_nullptr)
-- [**```DOCTEST_CONFIG_WITH_LONG_LONG```**](#doctest_config_with_long_long)
-- [**```DOCTEST_CONFIG_WITH_STATIC_ASSERT```**](#doctest_config_with_static_assert)
-- [**```DOCTEST_CONFIG_NO_DELETED_FUNCTIONS```**](#doctest_config_no_deleted_functions)
-- [**```DOCTEST_CONFIG_NO_RVALUE_REFERENCES```**](#doctest_config_no_rvalue_references)
-- [**```DOCTEST_CONFIG_NO_VARIADIC_MACROS```**](#doctest_config_no_variadic_macros)
-- [**```DOCTEST_CONFIG_NO_NULLPTR```**](#doctest_config_no_nullptr)
-- [**```DOCTEST_CONFIG_NO_LONG_LONG```**](#doctest_config_no_long_long)
-- [**```DOCTEST_CONFIG_NO_STATIC_ASSERT```**](#doctest_config_no_static_assert)
-
For most people the only configuration needed is telling **doctest** which source file should host all the implementation code:
### **```DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN```**
@@ -250,82 +235,12 @@
This can be defined both globally and in specific source files only.
-### **```DOCTEST_CONFIG_WITH_DELETED_FUNCTIONS```**
-
-doctest tries to detect if c++11 deleted functions are available but if it doesn't detect it - the user might define this.
-
-This should be defined globally.
-
-### **```DOCTEST_CONFIG_WITH_RVALUE_REFERENCES```**
-
-doctest tries to detect if c++11 rvalue references are available but if it doesn't detect it - the user might define this.
-
-This should be defined globally.
-
-### **```DOCTEST_CONFIG_WITH_VARIADIC_MACROS```**
-
-doctest tries to detect if c++11 variadic macros are available but if it doesn't detect it - the user might define this.
-
-This can be defined both globally and in specific source files only.
-
-### **```DOCTEST_CONFIG_WITH_NULLPTR```**
-
-doctest tries to detect if c++11 ```nullptr``` is available but if it doesn't detect it - the user might define this.
-
-This should be defined globally.
-
-### **```DOCTEST_CONFIG_WITH_LONG_LONG```**
-
-doctest tries to detect if c++11 ```long long``` is available but if it doesn't detect it - the user might define this.
-
-This should be defined globally.
-
-### **```DOCTEST_CONFIG_WITH_STATIC_ASSERT```**
-
-doctest tries to detect if c++11 ```static_assert()``` is available but if it doesn't detect it - the user might define this.
-
-This should be defined globally.
-
-### **```DOCTEST_CONFIG_NO_DELETED_FUNCTIONS```**
-
-If doctest detects c++11 deleted functions support as available but the user knows better - this can be defined to disable it.
-
-This should be defined globally.
-
-### **```DOCTEST_CONFIG_NO_RVALUE_REFERENCES```**
-
-If doctest detects c++11 rvalue references support as available but the user knows better - this can be defined to disable it.
-
-This should be defined globally.
-
-### **```DOCTEST_CONFIG_NO_VARIADIC_MACROS```**
-
-If doctest detects c++11 variadic macros support as available but the user knows better - this can be defined to disable it.
-
-This can be defined both globally and in specific source files only.
-
-### **```DOCTEST_CONFIG_NO_NULLPTR```**
-
-If doctest detects c++11 ```nullptr``` support as available but the user knows better - this can be defined to disable it.
-
-This should be defined globally.
-
-### **```DOCTEST_CONFIG_NO_LONG_LONG```**
-
-If doctest detects c++11 ```long long``` support as available but the user knows better - this can be defined to disable it.
-
-This should be defined globally.
-
-### **```DOCTEST_CONFIG_NO_STATIC_ASSERT```**
-
-If doctest detects c++11 ```static_assert()``` support as available but the user knows better - this can be defined to disable it.
-
-This should be defined globally.
-
---------------
[Home](readme.html#reference)
+<p align="center"><img src="../../scripts/data/logo/icon_2.svg"></p>
+
</xmp>
<script src="strapdown.js/strapdown.js"></script>
diff --git a/doc/html_generated/faq.html b/doc/html_generated/faq.html
index 56d5764..996f7e8 100644
--- a/doc/html_generated/faq.html
+++ b/doc/html_generated/faq.html
@@ -21,22 +21,22 @@
Pros of **doctest**:
+- **doctest** is [**thread-safe**](faq.html#is-doctest-thread-aware)
- including the **doctest** header is [**over 20 times lighter**](benchmarks.html#cost-of-including-the-header) on compile times than that of [**Catch**](https://github.com/philsquared/Catch)
- the asserts in **doctest** can be [**many times lighter**](benchmarks.html#cost-of-an-assertion-macro) on compile times than those of [**Catch**](https://github.com/philsquared/Catch)
- **doctest** executes tests [**many times faster**](benchmarks.html#runtime-benchmarks) than [**Catch**](https://github.com/philsquared/Catch)
- everything testing-related can be removed from the binary by defining the [**```DOCTEST_CONFIG_DISABLE```**](configuration.html#doctest_config_disable) identifier
- doesn't drag any headers when included (except for in the translation unit where the library gets implemented)
- 0 warnings even on the [**most aggressive**](../../scripts/cmake/common.cmake#L84) warning levels for MSVC/GCC/Clang
-- per commit tested with 300+ builds on [**much more compilers**](features.html#extremely-portable) - and through valgrind/sanitizers/analyzers
+- per commit tested with 180+ builds on [**much more compilers**](features.html#extremely-portable) - and through valgrind/sanitizers/analyzers
- test cases can be written in headers - the framework will still register the tests only once - no duplicates
Aside from everything mentioned so far doctest has some [**features**](features.html#other-features) (like [**templated test cases**](parameterized-tests.html#templated-test-cases---parameterized-by-type)) which [**Catch**](https://github.com/philsquared/Catch) doesn't.
Missing stuff:
-- a reporter/listener system - to a file, to xml, ability for the user to write their own reporter, etc.
- matchers and generators
-- other stuff
+- other small stuff
But these things (and more!) are planned in the [**roadmap**](roadmap.html)!
@@ -67,15 +67,13 @@
These 2 things can be considered negligible if you are dealing mainly with arithmetic (expressions are unlikely to throw exceptions) and all the tests usually pass (you don't need to often navigate to a failing assert with a debugger attached)
-If you want better aliases for the asserts instead of the long ones you could use [**```DOCTEST_CONFIG_NO_SHORT_MACRO_NAMES```**](configuration.html#doctest_config_no_short_macro_names) and then define your aliases like this: ```#define CHECK_EQ DOCTEST_FAST_CHECK_EQ``` (example in [**here**](../../examples/all_features/alternative_macros.cpp)).
+If you want better aliases for the asserts instead of the long ones you could use [**```DOCTEST_CONFIG_NO_SHORT_MACRO_NAMES```**](configuration.html#doctest_config_no_short_macro_names) and then define your aliases like this: ```#define CHECK_EQ DOCTEST_FAST_CHECK_EQ``` (example in [**here**](../../examples/all_features/alternative_macros.cpp) and [**here**](../../examples/all_features/doctest_proxy.h)).
### Is doctest thread-aware?
-Currently no. Asserts cannot be used in multiple threads and test cases cannot be ran in parallel. These are long-term features that are planned on the [**roadmap**](roadmap.html).
+Most macros/functionality is safe to use in a multithreaded context: [**assertion**](assertions.html) and [**logging**](logging.html) macros can be safely used from multiple threads spawned from a single test case. This however does not mean that multiple test cases can be ran in parallel - test cases are still ran serially. [**Subcases**](tutorial.html#test-cases-and-subcases) should also be used only from the test runner thread - not following these instructions will lead to crashes (example in [**here**](../../examples/all_features/concurrency.cpp)). Also note that logged context in one thread will not be used/printed when asserts from another thread fail - logged context is thread-local.
-For now tests are ran serially and doing asserts in multiple user threads will lead to crashes.
-
-There is an option to run a [**range**](commandline.html) of tests from an executable - so ran in parallel with multiple process invocations - see [**the example python script**](../../examples/range_based_execution.py).
+There is also an option to run a [**range**](commandline.html) of tests from an executable - so tests can be ran in parallel by invoking the process multiple times with different ranges - see [**the example python script**](../../examples/range_based_execution.py).
### Is mocking supported?
@@ -154,6 +152,8 @@
[Home](readme.html#reference)
+<p align="center"><img src="../../scripts/data/logo/icon_2.svg"></p>
+
</xmp>
<script src="strapdown.js/strapdown.js"></script>
diff --git a/doc/html_generated/features.html b/doc/html_generated/features.html
index 456d4a5..7affb68 100644
--- a/doc/html_generated/features.html
+++ b/doc/html_generated/features.html
@@ -26,19 +26,19 @@
## Extremely portable:
-- Standards compliant **C++98** code - should work with any **C++98** compiler
-- tested with **GCC**: **4.4**, **4.5**, **4.6**, **4.7**, **4.8**, **4.9**, **5**, **6**, **7**, **8**
-- tested with **Clang**: **3.5**, **3.6**, **3.7**, **3.8**, **3.9**, **4**, **5**, **6**
-- tested with **MSVC**: **2008**, **2010**, **2012**, **2013**, **2015**, **2017**
-- per-commit tested on **travis** and **appveyor** CI services
+- Standards compliant **C++11** code - should work with any **C++11** capable compiler (use tag [**1.2.9**](https://github.com/onqtam/doctest/tree/1.2.9) for C++98 and older compilers)
+- tested with **GCC**: **4.8**, **4.9**, **5**, **6**, **7**, **8**
+- tested with **Clang**: **3.5**, **3.6**, **3.7**, **3.8**, **3.9**, **4**, **5**, **6** (XCode 8+)
+- tested with **MSVC**: **2015**, **2017** (also in 32 bit mode)
+- per-commit tested on [**travis**](https://travis-ci.org/onqtam/doctest) and [**appveyor**](https://ci.appveyor.com/project/onqtam/doctest) CI services
- warnings as errors even on the most aggressive warning levels - see [**here**](../../scripts/cmake/common.cmake#L84)
- statically analyzed on the CI - [**Cppcheck**](http://cppcheck.sourceforge.net/) / [**Clang-Tidy**](http://oclint.org/) / [**Coverity Scan**](https://scan.coverity.com/) / [**OCLint**](https://scan.coverity.com/) / [**Visual Studio Analyzer**](https://docs.microsoft.com/en-us/visualstudio/code-quality/analyzing-c-cpp-code-quality-by-using-code-analysis)
- all tests have their output compared to reference output of a previous known good run
- - all tests built and ran in **Debug**/**Release** and also in **32**/**64** bit modes
- - all tests ran through **valgrind** under **Linux**/**OSX**
- - all tests ran through **address** and **UB** sanitizers under **Linux**/**OSX**
- - tests are ran in more than **330** different configurations on UNIX (Linux + OSX) on **travis** CI
- - tests are ran in a total of **24** different configurations on Windows on **appveyor** CI
+ - all tests built and ran in **Debug**/**Release** modes
+ - all tests ran through **valgrind** under **Linux** (sadly [not under OSX](https://github.com/onqtam/doctest/issues/11))
+ - all tests ran through **address**, **UB** and **thread** sanitizers under **Linux**/**OSX**
+ - tests are ran in more than **168** different configurations on UNIX (Linux + OSX) on **travis** CI
+ - tests are ran in a total of **10** different configurations on Windows on **appveyor** CI
## Other features:
@@ -50,11 +50,14 @@
- [**templated test cases**](parameterized-tests.html#templated-test-cases---parameterized-by-type) - parameterized by type
- supports [**logging macros**](logging.html) for capturing local variables and strings - as a message for when an assert fails - with lazy stringification and no allocations when possible!
- crash handling support - uses signals for UNIX and SEH for Windows
+- [**thread-safe**](faq.html#is-doctest-thread-aware) - asserts (and logging) can be used from multiple threads spawned from a single test case - [**example**](../../examples/all_features/concurrency.cpp)
+- an extensible [**reporter system**](reporters.html) (can be also used for implementing event listeners)
- output from all compilers on all platforms is the same - byte by byte
- binaries (exe/dll) can use the test runner of another binary - so tests end up in a single registry - [**example**](../../examples/executable_dll_and_plugin/)
- supports [**BDD style**](testcases.html) tests
- one core [**assertion macro**](assertions.html) for comparisons - standard C++ operators are used for the comparison (less than, equal, greater than...) - yet the full expression is decomposed and left and right values of the expression are logged
-- assertion macros for [**exceptions**](assertions.html) - if something should or shouldn't throw
+- asserts can be used [**outside of a testing context**](assertions.html#using-asserts-out-of-a-testing-context) - [**example**](../../examples/all_features/asserts_used_outside_of_tests.cpp)
+- assertion macros for [**exceptions**](assertions.html#exceptions) - if something should or shouldn't throw
- floating point comparison support - see the [**```Approx()```**](assertions.html#floating-point-comparisons) helper
- powerful mechanism for [**stringification**](stringification.html) of user types - including [**exceptions**](stringification.html#translating-exceptions)!
- tests can be grouped in [**test suites**](testcases.html#test-suites)
@@ -72,7 +75,7 @@
- colored output in the console
- controlling the order of test execution
- different ```doctest::Context```s can be created and ran many times within a single execution of the program
-- ability to query if code is currently being ran in a test - ```doctest::isRunningInTest()```
+- ability to query if code is currently being ran in a test - ```doctest::is_running_in_test```
There is a list of planned features which are all important and big - see the [**roadmap**](roadmap.html).
@@ -80,6 +83,8 @@
[Home](readme.html#reference)
+<p align="center"><img src="../../scripts/data/logo/icon_2.svg"></p>
+
</xmp>
<script src="strapdown.js/strapdown.js"></script>
diff --git a/doc/html_generated/logging.html b/doc/html_generated/logging.html
index 04c9583..525e2e7 100644
--- a/doc/html_generated/logging.html
+++ b/doc/html_generated/logging.html
@@ -5,7 +5,7 @@
## Logging macros
-Additional messages can be logged during a test case.
+Additional messages can be logged during a test case (safely even in [**concurrent threads**](faq.html#is-doctest-thread-aware)).
## INFO()
@@ -89,6 +89,8 @@
[Home](readme.html#reference)
+<p align="center"><img src="../../scripts/data/logo/icon_2.svg"></p>
+
</xmp>
<script src="strapdown.js/strapdown.js"></script>
diff --git a/doc/html_generated/main.html b/doc/html_generated/main.html
index d77acc4..5e1cf79 100644
--- a/doc/html_generated/main.html
+++ b/doc/html_generated/main.html
@@ -64,6 +64,8 @@
[Home](readme.html#reference)
+<p align="center"><img src="../../scripts/data/logo/icon_2.svg"></p>
+
</xmp>
<script src="strapdown.js/strapdown.js"></script>
diff --git a/doc/html_generated/parameterized-tests.html b/doc/html_generated/parameterized-tests.html
index cb59bc5..e3bf51a 100644
--- a/doc/html_generated/parameterized-tests.html
+++ b/doc/html_generated/parameterized-tests.html
@@ -114,9 +114,7 @@
- directly pass the list of types to the templated test case
```
- typedef doctest::Types<char, short, int, long long int> the_types;
-
- TEST_CASE_TEMPLATE("signed integers stuff", T, the_types) {
+ TEST_CASE_TEMPLATE("signed integers stuff", T, char, short, int, long long int) {
T var = T();
--var;
CHECK(var == -1);
@@ -132,11 +130,9 @@
CHECK(var == -1);
}
- typedef doctest::Types<char, short, int, long long int> the_types;
- TEST_CASE_TEMPLATE_INSTANTIATE(test_id, the_types);
+ TEST_CASE_TEMPLATE_INSTANTIATE(test_id, char, short, int, long long int);
- typedef doctest::Types<float, double> the_types_2;
- TEST_CASE_TEMPLATE_INSTANTIATE(test_id, the_types_2);
+ TEST_CASE_TEMPLATE_INSTANTIATE(test_id, float, double);
```
If you are designing an interface or concept, you can define a suite of type-parameterized tests to verify properties that any valid implementation of the interface/concept should have. Then, the author of each implementation can just instantiate the test suite with his type to verify that it conforms to the requirements, without having to write similar tests repeatedly.
@@ -161,8 +157,6 @@
- types are NOT filtered for uniqueness - the same templated test case can be instantiated multiple times for the same type - preventing that is left up to the user
- you don't need to provide stringification for every type as that plays a role only in the test case name - the default is ```<>``` - the tests will still work and be distinct
-- the ```doctest::Types<>``` template accepts up to 60 type arguments
-- if variadic macros are enabled (see [**```DOCTEST_CONFIG_WITH_VARIADIC_MACROS```**](configuration.html#doctest_config_with_variadic_macros)) the typedefs can be skipped and the type lists can be constructed directly in the macros - otherwise the compiler will think that each comma in the type list introduces a new macro argument. With variadic macro support the ```TYPE_TO_STRING``` macro will also be able to work with types such as ```std::pair<int, float>```.
- if you need parameterization on more than 1 type you can package multiple types in a single one like this:
```
@@ -173,10 +167,9 @@
typedef second B;
};
- typedef Types<
- TypePair<int, char>,
+ #define pairs \
+ TypePair<int, char>, \
TypePair<char, int>
- > pairs;
TEST_CASE_TEMPLATE("multiple types", T, pairs) {
typedef typename T::A T1;
@@ -193,6 +186,8 @@
[Home](readme.html#reference)
+<p align="center"><img src="../../scripts/data/logo/icon_2.svg"></p>
+
</xmp>
<script src="strapdown.js/strapdown.js"></script>
diff --git a/doc/html_generated/readme.html b/doc/html_generated/readme.html
index 82e430e..a1c7fd9 100644
--- a/doc/html_generated/readme.html
+++ b/doc/html_generated/readme.html
@@ -34,6 +34,10 @@
[](http://www.patreon.com/onqtam)
[](https://www.paypal.me/onqtam/10)
+------------
+
+<p align="center"><img src="../../scripts/data/logo/icon_2.svg"></p>
+
</xmp>
<script src="strapdown.js/strapdown.js"></script>
diff --git a/doc/html_generated/roadmap.html b/doc/html_generated/roadmap.html
index 853649b..08beabb 100644
--- a/doc/html_generated/roadmap.html
+++ b/doc/html_generated/roadmap.html
@@ -12,41 +12,44 @@
Planned features for future releases - order changes constantly...
-### For 1.3:
+### For 2.1:
-- reporters
- - output to file
- - a system for writing custom reporters
- - ability to use multiple reporters at once (but only 1 to stdout)
- - a compact reporter
- - a progress reporter - or maybe just an option for the console reporter
- - an xml reporter ([junit related stuff](https://github.com/ujiro99/doctest-junit-report))
- - xUnit reporter
- - a listener interface - similar to a reporter - look at Catch
-- ability to have no output when everything succeeds
-- option to output summary only
-- thread safety - asserts/subcases/captures should be safe to be used by multiple threads simultaneously
- - https://github.com/blastrock/doctest/tree/threadsafe
+- finish the reporter system
+ - what is done:
+ - can be used for listening for events
+ - multiple reporters can be used
+ - custom reporters can be written
+ - register and choose reporters
+ - list all reporters
+ - what is left:
+ - output to file (or just not stdout)
+ - xml output
+ - xUnit reporter
+ - compact reporter - https://github.com/onqtam/doctest/issues/75
+ - progress reporter
+ - [junit related stuff](https://github.com/ujiro99/doctest-junit-report))
+ - options
+ - absolutely no output on success
+ - summary only
+ - make sure all relevant parts of the reporters can be accessed from the doctest namespace without the need for detail
+ - examples
+ - documentation
- matchers - should investigate what they are - look at google test/mock and Catch (also predicates and boost test)
+
+### For 2.2:
+
+- header with extensions
+ - demangling with the use of the cxxabi header
+ - stringification of types from std, also enums with the help of traits as discussed in #121
+ - esoteric reporters
- convolution support for the assertion macros (with a predicate)
-
-### For 1.4:
-
- Value-Parameterized test cases
- generators? - look at Catch - and investigate what they are
- look at property based testing
- [rapidcheck](https://github.com/emil-e/rapidcheck)
- [autocheck](https://github.com/thejohnfreeman/autocheck)
- [CppQuickCheck](https://github.com/grogers0/CppQuickCheck)
-- proper conan package
- - https://github.com/onqtam/doctest/issues/103
- - https://github.com/bincrafters/conan-doctest
- - https://github.com/uilianries/conan-catch
- - https://github.com/philsquared/Catch/pull/938
- - https://stackoverflow.com/questions/40311363/conan-io-header-only-package
- - https://github.com/conan-io/docs/issues/67
- - https://github.com/agauniyal/rang
- - https://github.com/conan-io/conan/issues/324
+- proper conan package - https://github.com/onqtam/doctest/issues/103
- IDE integration
- https://blogs.msdn.microsoft.com/vcblog/2017/05/10/unit-testing-and-the-future-announcing-the-test-adapter-for-google-test/
- https://www.reddit.com/r/cpp/comments/65c0f1/run_cpp_unit_tests_from_xcode_and_visual_studio/
@@ -63,7 +66,7 @@
- https://www.jetbrains.com/clion/features/unit-testing.html
- https://blog.jetbrains.com/clion/2017/03/clion-2017-1-released/#catch
-### For 1.5:
+### For 2.3:
- log levels - like in [boost test](http://www.boost.org/doc/libs/1_63_0/libs/test/doc/html/boost_test/utf_reference/rt_param_reference/log_level.html)
- running tests a [few times](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.html#repeating-the-tests)
@@ -86,16 +89,6 @@
- should test C++11 stuff - perhaps inspect the CMAKE_CXX_FLAGS for -std=c++11 on the CI and add more targets/tests
- test tricky stuff like expressions with commas in asserts
-### For 2.0:
-
-- remove C++98 support
- - remove the config identifiers for C++11 features
- - use variadic templates where appropriate
- - update type lists to C++11
- - update traits - use declval, etc.
- - move initialization of fields from initializer lists to class bodies
- - update static code analysis - less warning suppressing
-
### For 3.0:
- use modules - use ```std::string``` and whatever else comes from the standard - no more hand rolled traits and classes
@@ -103,6 +96,9 @@
### Things that are being considered but not part of the roadmap yet:
+- add LIKELY & friends for the conditions of asserts - look at BOOST_LIKELY, ppk_assert, foonathan/debug_assert, etc
+- ability for users to register their own command line options and access them later on
+- fix this: https://github.com/catchorg/Catch2/issues/1292
- FakeIt mocking integration - like [catch](https://github.com/eranpeer/FakeIt/tree/master/config/catch) (also checkout [this](https://github.com/ujiro99/doctest-sample))
- look into https://github.com/cpp-testing/GUnit - https://www.youtube.com/watch?v=NVrZjT5lW5o
- consider the following 2 properties for the MSVC static code analyzer: EnableCppCoreCheck, EnableExperimentalCppCoreCheck
@@ -115,6 +111,7 @@
- checkpoint/passpoint - like in [boost test](http://www.boost.org/doc/libs/1_63_0/libs/test/doc/html/boost_test/test_output/test_tools_support_for_logging/checkpoints.html) (also make all assert/subcase/logging macros to act as passpoints and print the last one on crashes or exceptions)
- queries for the current test case - name (and probably decorators)
- support for LibIdentify
+- add CHECKED_IF & friends: https://github.com/catchorg/Catch2/issues/1278
- support for running tests in parallel in multiple threads
- death tests - as in [google test](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.html#death-tests)
- config options
@@ -145,19 +142,25 @@
- or just ignore all of this this - it would require globals or classes and inheritance - and we already have subcases
- doctest in a GUI environment? with no console? APIs for attaching a console? querying if there is one? [investigate...](https://github.com/philsquared/Catch/blob/master/docs/configuration.html#stdout)
- runtime performance
+ - look at this: https://github.com/catchorg/Catch2/issues/1086
- startup - the set holding all registered tests should use a specialized allocator to minimize program startup time
- - failing - optimize createStream/freeStream to reuse a pool of ostringstream objects
+ - optimize the mutex lock:
+ - http://preshing.com/20111124/always-use-a-lightweight-mutex/
+ - http://preshing.com/20120226/roll-your-own-lightweight-mutex/
- ability to provide a temp folder that is cleared between each test case
- make the _MESSAGE assert macros work with variadic arguments - and maybe write the ones for binary/unary/fast asserts as well
- move from operator "<<" to "<=" for capturing the left operand when decomposing binary expressions with templates
- think about silencing warnings about unused variables when DOCTEST_CONFIG_DISABLE is used - see commit 6b61e8aa3818c5ea100cedc1bb48a60ea10df6e8 or issue #61
+ - also this: ```(void)(true ? (void)0 : ((void)(expression)))```
- think about optionally using ```<typeinfo>``` and libcxxabi for demangling so users don't have to use ```TYPE_TO_STRING()```
- handle more complex expressions - ```CHECK(foo() == 1 || bar() == 2);```
+- add [[noreturn]] to MessageBuilder::react() - and actually make a separate function (react2) for the FAIL() case
- think about using a string view of some sorts
- benchmark against google test and boost test
### Things that are very unlikely to enter the roadmap:
+- rethink static code analysis suppressions - users shouldn't have to use the same flags for code which uses doctest macros/types
- think about removing the binary asserts (leaving only the fast binary asserts) because normal asserts + no try/catch in asserts are almost the same
- move the "react()" part (the one that throws for REQUIRE asserts - or for when "abort-after=<int>" is reached) to a function call in the while() part of the asserts
- stop using underscores for the begining of identifiers - the anonymous variables - against the standard...
@@ -179,6 +182,8 @@
[Home](readme.html#reference)
+<p align="center"><img src="../../scripts/data/logo/icon_2.svg"></p>
+
</xmp>
<script src="strapdown.js/strapdown.js"></script>
diff --git a/doc/html_generated/stringification.html b/doc/html_generated/stringification.html
index b6392ef..a772a5b 100644
--- a/doc/html_generated/stringification.html
+++ b/doc/html_generated/stringification.html
@@ -95,6 +95,8 @@
[Home](readme.html#reference)
+<p align="center"><img src="../../scripts/data/logo/icon_2.svg"></p>
+
</xmp>
<script src="strapdown.js/strapdown.js"></script>
diff --git a/doc/html_generated/testcases.html b/doc/html_generated/testcases.html
index b6605e6..267bc6e 100644
--- a/doc/html_generated/testcases.html
+++ b/doc/html_generated/testcases.html
@@ -5,9 +5,7 @@
## Test cases
-While **doctest** fully supports the traditional, xUnit, style of class-based fixtures containing test case methods this is not the preferred style.
-
-Instead **doctest** provides a powerful mechanism for nesting subcases within a test case. For a more detailed discussion see the [**tutorial**](tutorial.html#test-cases-and-subcases).
+While **doctest** fully supports the traditional, xUnit, style of class-based fixtures containing test case methods this is not the preferred style. Instead **doctest** provides a powerful mechanism for nesting subcases within a test case. For a more detailed discussion see the [**tutorial**](tutorial.html#test-cases-and-subcases).
Test cases and subcases are very easy to use in practice:
@@ -16,6 +14,8 @@
_test name_ and _subcase name_ are free form, quoted, strings. Test names don't have to be unique within the **doctest** executable. They should also be string literals.
+Keep in mind that even though **doctest** is [**thread-safe**](faq.html#is-doctest-thread-aware) - using subcases has to be done only in the main test runner thread.
+
For examples see the [Tutorial](tutorial.html)
Test cases can also be parameterized - see the [documentation](parameterized-tests.html)
@@ -59,27 +59,26 @@
```
class UniqueTestsFixture {
- private:
- static int uniqueID;
- protected:
- DBConnection conn;
- public:
- UniqueTestsFixture() : conn(DBConnection::createConnection("myDB")) {
- }
- protected:
- int getID() {
- return ++uniqueID;
- }
- };
+private:
+ static int uniqueID;
+protected:
+ DBConnection conn;
+public:
+ UniqueTestsFixture() : conn(DBConnection::createConnection("myDB")) {}
+protected:
+ int getID() {
+ return ++uniqueID;
+ }
+};
- int UniqueTestsFixture::uniqueID = 0;
+int UniqueTestsFixture::uniqueID = 0;
- TEST_CASE_FIXTURE(UniqueTestsFixture, "Create Employee/No Name") {
- REQUIRE_THROWS(conn.executeSQL("INSERT INTO employee (id, name) VALUES (?, ?)", getID(), ""));
- }
- TEST_CASE_FIXTURE(UniqueTestsFixture, "Create Employee/Normal") {
- REQUIRE(conn.executeSQL("INSERT INTO employee (id, name) VALUES (?, ?)", getID(), "Joe Bloggs"));
- }
+TEST_CASE_FIXTURE(UniqueTestsFixture, "Create Employee/No Name") {
+ REQUIRE_THROWS(conn.executeSQL("INSERT INTO employee (id, name) VALUES (?, ?)", getID(), ""));
+}
+TEST_CASE_FIXTURE(UniqueTestsFixture, "Create Employee/Normal") {
+ REQUIRE(conn.executeSQL("INSERT INTO employee (id, name) VALUES (?, ?)", getID(), "Joe Bloggs"));
+}
```
The two test cases here will create uniquely-named derived classes of UniqueTestsFixture and thus can access the `getID()` protected method and `conn` member variables. This ensures that both the test cases are able to create a DBConnection using the same method (DRY principle) and that any ID's created are unique such that the order that tests are executed does not matter.
@@ -171,6 +170,8 @@
[Home](readme.html#reference)
+<p align="center"><img src="../../scripts/data/logo/icon_2.svg"></p>
+
</xmp>
<script src="strapdown.js/strapdown.js"></script>
diff --git a/doc/html_generated/tutorial.html b/doc/html_generated/tutorial.html
index 4d08dc3..ab9a62e 100644
--- a/doc/html_generated/tutorial.html
+++ b/doc/html_generated/tutorial.html
@@ -180,6 +180,8 @@
Subcases can be nested to an arbitrary depth (limited only by your stack size). Each leaf subcase (a subcase that contains no nested subcases) will be executed exactly once on a separate path of execution from any other leaf subcase (so no leaf subcase can interfere with another). A fatal failure in a parent subcase will prevent nested subcases from running - but then that's the idea.
+Keep in mind that even though **doctest** is [**thread-safe**](faq.html#is-doctest-thread-aware) - using subcases has to be done only in the main test runner thread.
+
## Scaling up
To keep the tutorial simple we put all our code in a single file. This is fine to get started - and makes jumping into **doctest** even quicker and easier. This is not really the best approach when you start writing more real-world tests.
@@ -205,6 +207,8 @@
[Home](readme.html#reference)
+<p align="center"><img src="../../scripts/data/logo/icon_2.svg"></p>
+
</xmp>
<script src="strapdown.js/strapdown.js"></script>