Roadmap

This library is free, and will stay free but needs your support to sustain its development. There are lots of new features and maintenance to do. If you work for a company using doctest or have the means to do so, please consider financial support.

Pledgie Patreon PayPal

Planned features for future releases - order may change.

For 1.2:

  • running tests a few times

  • ability to filter not just TEST_CASE names but also SUBCASE names (and maybe tags when they are introduced)

  • 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); and extend the asserts to have _AT variants)

  • Parametric test cases (Value/Type-parameterized tests) - https://github.com/onqtam/doctest/issues/38

  • crash handling: signals on UNIX platforms or structured exceptions on Windows (should also have DOCTEST_CONFIG_NO_SIGNAL_CATCHING)

  • change docs a bit - mainly what is in the landing page (add link to overload)

For 1.3:

  • builds with GCC 7 when it is released (should be in late April) - also by then the precise (ubuntu 12.04) ppa for clang 4.0 should be whitelisted by travis
  • 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
    • an xml reporter
    • jUnit/xUnit reporters
    • a listener interface - similar to a reporter - look at Catch
  • time stuff
    • reporting running time of tests
    • count a test case as failed if it exceeds X ms (but no force-killing!)
    • killing a test that exceeds a time limit (will perhaps require threading or processes)
  • matchers - should investigate what they are - look at google test and Catch
  • convolution support for the assertion macros (with a predicate)
  • 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 - lest integrates with trompeloeil like this
  • look at property based testing (for example rapidcheck) - and write in FAQ
  • implement breaking into the debugger under linux - see here and here

For 1.4:

  • runtime performance
    • the set holding all registered tests should use a specialized allocator to minimize program startup time
    • lazily stringify expressions - only when needed
    • pool allocator for the String class - currently very unoptimized
    • get rid of local statics on the hot path - like in getContextState() - they have synchronisation in C++11
  • benchmarking
    • make the bench.py script more usable - with command line arguments
    • redo the compile time ones - also look into CATCH_CONFIG_FAST_COMPILE
    • remove old benchmarks for doctest 1.0
    • add runtime benchmarks
  • test execution in separate processes - fork() for UNIX and this for Windows
  • 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

Things that are being considered but not part of the roadmap yet:

  • failure reporting should print out previous SECTIONs for data-driven testing - as requested here
  • Bitwise() class that has overloaded operators for comparison - to be used to check objects bitwise against each other
  • detect floating point exceptions
  • ability to customize the colors in the console output (may also use styles - based on this)
  • option to output summary only
  • support for tags
  • marking a test to run X times (should also multiply with the global test run times)
  • add a "wait key" option - as requested here
  • add Approx ability to compare with absolute epsilon - Catch PR
  • 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
  • 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
  • look into MSTest integration
  • ability to provide a temp folder that is cleared between each test case
  • ability to make the framework not capture unexpected exceptions - as requested here
  • rework the examples folder - so the test runner is compiled only a few times - CI builds take a ton of time!

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