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.

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
• 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.md#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)
• add ERROR/FAIL macros (also ADD_FAILURE_AT(file, line);)
• 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 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
  • https://msdn.microsoft.com/en-us/library/hh598953.aspx
  • also look into similar Xcode integration - https://github.com/philsquared/Catch/pull/454
• matchers - should investigate what they are - look at google test and Catch
• generators? - look at Catch - and investigate what they are (also in boost)
• mocking - investigate google mock assertion macros and interop with doctest (also mockitopp and trompeloeil) - and write in FAQ
• look at property based testing (for example rapidcheck) - and write in FAQ
• symbolizer - for a stack trace - when an assertion fails - and it's in a user function with some deep callstack away from the current test case - how to know the exact code path that lead to the failing assert

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
• extend Approx for types that have operator double - see here and here
• 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

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 libraries can

---

Home