There are many c++ testing frameworks - Catch, Boost.Test, UnitTest++, lest, bandit, igloo, xUnit++, CppTest, CppUnit, CxxTest, cpputest, googletest, cute and many many other.
doctest is much lighter and is unintrusive. It also offers a way to remove everything testing-related from the binary.
This allows the library to be used in more ways - tests can be written in the production code - just like with the unittest {} functionality in the D programming language.
Even if you don't see the ability of writing tests in your production code as beneficial the library can still be used like any other - it is (almost) on par with the rest as far as features go and is much lighter and portable (and might have better defaults). See the features
doctest namespace (and the implementation details are in a nested detail namespace)-Weverything -pedantic for clang-Wall -Wextra -pedantic and >> over 50 << other warnings not covered by these flags for GCC!!! - see here/W4 for MSVC (/Wall is too much there - even their own headers produce thousands of warnings with that option)argc/argv from the command lineThis library was modeled after Catch and lest - especially the subcases and the expression decomposition macros.
#(features)
DOCTEST_CONFIG_DISABLE macronew/delete (only malloc) so you can test your operator new()look at catch command line options (also lest)
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
kosta - test pledgie
the help!
examples and test coverage
enabling COMPARE in tests
test for warnings with -std=c++03/11/14/1z
benchmark (assimp and empty files - or maybe just empty files)
documentation
pledgie campaign - more info
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)
ability to transfer/copy registered functions from one dll to another so they are put in one set and duplicates are filtered
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
for gamedev - compile time!
https://www.facebook.com/groups/IndieGameDevs/
facebook fmi group
https://github.com/nothings/stb/blob/master/docs/other_libs.md
suggest to be linked to in https://github.com/nothings/stb