| <!DOCTYPE html> |
| <html> |
| <title>roadmap</title> |
| <xmp theme="united" style="display:none;"> |
| |
| ## Roadmap |
| |
| Support the development of the project with donations! I work on this project in my spare time and every cent is a big deal. |
| |
| If you work for a company using doctest or have the means to do so, please consider financial support. |
| |
| [](https://pledgie.com/campaigns/31280) |
| [](http://www.patreon.com/onqtam) |
| [](https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=3K423Q6TK48BN) |
| |
| This is a list of planned features for future releases (not in the given order). |
| |
| - option to output summary only |
| - ability to customize the colors in the console output |
| - add support for <=, >= to Approx - like requested with [catch](https://github.com/philsquared/Catch/issues/651) |
| - the set holding all registered tests should use a specialized allocator to minimize program startup time |
| - pool allocator for the ```String``` class - currently very unoptimized |
| - a mechanism for translating exceptions - users should be able to teach the framework about their types (look at Catch) |
| - support for ```std::exception``` and derivatives (mainly for calling the ```.what()``` method when caught unexpectedly) |
| - crash handling: signals on UNIX platforms or structured exceptions on Windows (should also have DOCTEST_CONFIG_NO_SIGNAL_CATCHING) |
| - support for tags |
| - may fail tag |
| - invisible tag |
| - look at Catch - https://github.com/philsquared/Catch/blob/master/docs/test-cases-and-sections.html#special-tags |
| - output to file |
| - reporters |
| - a system for writing custom reporters |
| - ability to use multiple reporters at once (but only 1 to stdout) |
| - a compact reporter |
| - an xml reporter |
| - jUnit/xUnit reporters |
| - add the ability to query if code is currently being ran in a test - ```doctest::isRunningInTest()``` |
| - convolution support for the assertion macros (with a predicate) |
| - time stuff |
| - reporting running time of tests |
| - restricting duration of test cases |
| - killing a test that exceeds a time limit (will perhaps require threading or processes) |
| - adding contextual info to asserts (logging) - with an ```INFO```/```CONTEXT``` /```TRACEPOINT``` macro (also look at [this](https://github.com/philsquared/Catch/issues/601)) |
| - add ```ERROR```/```FAIL``` macros |
| - running tests a few times |
| - marking a test to run X times (should also multiply with the global test run times) |
| - test execution in separate processes - ```fork()``` for UNIX and [this](https://github.com/nemequ/munit/issues/2) for Windows |
| - ability to provide a temp folder that is cleared between each test case |
| - detect floating point exceptions |
| - ```Bitwise()``` class that has overloaded operators for comparison - to be used to check objects bitwise against each other |
| - look into MSTest integration |
| - http://accu.org/index.php/journals/1851 |
| - https://msdn.microsoft.com/en-us/library/hh270865.aspx |
| - also look into similar Xcode integration - https://github.com/philsquared/Catch/pull/454 |
| - matchers - should investigate what they are :D |
| - generators? - look at Catch - and investigate what they are (also in [boost](http://www.boost.org/doc/libs/1_61_0/libs/test/doc/html/boost_test/tests_organization/test_cases/test_case_generation.html) |
| - mocking - investigate google mock assertion macros and interop with doctest (also [mockitopp](https://github.com/tpounds/mockitopp)) - and write in FAQ |
| - look at property based testing (for example [rapidcheck](https://github.com/emil-e/rapidcheck)) - and write in FAQ |
| |
| And here is a list of things that are being considered but not part of the roadmap yet: |
| |
| - ability to have no output when everything succeeds |
| - integrate static analysis on the CI: **msvc**, **clang**, **cppcheck** |
| - add C++11 builds for gcc/clang (with -std=c++0x) |
| - option to list files in which there are test cases who match the current filters |
| - support for doing assertions in multiple threads - synchronize their access to shared doctest state |
| - support for running tests in parallel in multiple threads |
| - a progress reporter |
| - ability to filter not just TEST_CASE names but also SUBCASE names (and maybe tags when they are introduced) |
| - doctest in a GUI environment? with no console? APIs for attaching a console? querying if there is one? investigate... |
| - ability to specify ASC/DESC for the order option |
| - command line error handling/reporting |
| - ability for the user to extend the command line - as requested [here](https://github.com/philsquared/Catch/issues/622) |
| |
| The following list is with things that are very unlikely to enter the roadmap: |
| |
| - test with missed warning flags for GCC - look into https://github.com/Barro/compiler-warnings |
| - utf8??? |
| - handle ```wchar``` strings??? |
| - print a warning when no assertion is encountered in a test case |
| - hierarchical test suites - using a stack for the pushed ones - should be easy |
| - ability to re-run only newly compiled tests based on time stamps using ```__DATE__``` and ```__TIME__``` - stored in some file |
| - add option to not report line numbers - getting annoyed of re-committing reference output files with changed line reports from a tiny change... |
| - add underscores to all preprocessor identifiers not intended for use by the user |
| - put everything from the ```detail``` namespace also in a nested anonymous namespace to make them with internal linkage |
| - ability to put everything from doctest into an anonymous namespace - to allow the use of multiple different versions of **doctest** within the same binary (executable/dll) - like the [**stb**](https://github.com/nothings/stb) libraries can |
| |
| --------------- |
| |
| [Home](readme.html#reference) |
| |
| |
| </xmp> |
| <script src="strapdown.js/strapdown.js"></script> |
| </html> |