doc/markdown/todo.md

look at catch command line options (also lest)
detect floating point exceptions
colors
sorting the test order (also RAND! and SEED!) (by file, by test suite, or both, ASC/DESC...)
signal handling for unix: http://www.cplusplus.com/reference/csignal/signal/ (signals on *NIX platforms or structured exceptions on Windows)
colors in output
MSVC/IDE integration
make a compact reporter (for within ide-s - just the file and line number)
streaming reporters???
xml reporter (jUnit compatible, etc.)
think about the expression decomposition static asserts
test coverage
enabling COMPARE in tests
the help!
kosta - test pledgie
test for warnings with -std=c++03/11/14/1z
benchmark (assimp and empty files - or maybe just empty files)
documentation
CONTRIBUTING.md - pull requests, travis, formatting, etc.
pledgie campaign - more info

FUTURE

gcc 6
pool allocator for String class
Bitwise() class that has overloaded operators for comparison - to be used to check objects bitwise against each other
floating point comparison support
Bitwise() class that has overloaded operators for comparison - to be used to check objects bitwise against each other
timing reports of tests, duration restrictions, kill of longer than (will perhaps require threading), etc...
test execution in separate processes - UNIX only with fork() (but windows has some .dll which could help)
matchers?
[CI] static analysis: msvc, clang, cppcheck
[CI] mingw-w64 on appveyor

BDD based on the subtests - like Catch
tagging? also see this: https://github.com/philsquared/Catch/blob/master/docs/test-cases-and-sections.md#special-tags
utf8?
a message macro (also tracepoint/passpoint/info/context and whatever - like in boost.test) (ALSO ERROR/FAIL - like boost)
add WARN as third option to CHECK/REQUIRE versions of assertions
hierarchical test suites? using a stack for the pushed states - should be easy
ability to re-run only newly compiled tests - based on timestamps of the FILE in which they are - and stored in some file
put internals in anonymous namespace (even if already in detail) - even though clang-format will make everything more indented
wchar stuff in stringify and whatever - see <wchar.h>
progress of tests being executed (and an option for it)
think about adding support for std::exception and others
think about parameterising the output alignment to 80 or some other column limit
think about the ability to mix different versions of the library within the same executable (like stb libraries)
silencing warnings - take into account when a compiler (which version) accuires a pragma/attribute/warning (for gcc use -Wno-unknown-warning)
ability to transfer/copy registered functions from one dll to another so they are put in one set and duplicates are filtered

for gamedev - compile time!

"the latest and greatest in unit testing in c++"

180 builds linux/osx (+12 if clang 3.4/3.5/3.6 get the 32 bit sanitizer stuff) 20 builds windows

VC6 subcases not working - set a bounty on this: http://stackoverflow.com/questions/36940730/preprocessor-problems-with-vc6 VC6 - templated stringify() overloads will not compile

mimic catch front page - tutorial link, what is different link, documentation link.
profile doctest vs Catch (compile/startup)
defense of macros in testing frameworks: http://accu.org/var/uploads/journals/Overload125.pdf
whats the library's main purpose
warning free even with the most aggressive options for all 3 major compilers
mocking is not included because it is orthogonal to testing and a different third party library may be used for that (google mock) https://github.com/tpounds/mockitopp
check what features catch/lest have to offer (and what they say they lack)
FAQ - linker issues (_IMPLEMENT, etc)...
property based testing - what it is and how to use it with doctest
document how to use spaces for filters in the comma separated list (using "")
tests are ran serially
listing reporters or counting tests implies no_run
document all the options
initially was planning on a C version of the library but figured that there is no reason to choose C over C++ anywhere
tests in headers... might end up in different test suites - and only 1 of them will get registered? or might have ifdef-ed parts that get compiled differently based on how/where the header is included...... so not a good practice to write tests in header files
how subtests work - http://pastebin.com/rwghFzK4