blob: 51ac77bceff32f12b6b326020c00b3b388042b52 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
<!DOCTYPE html>
<html>
<title>roadmap</title>
<xmp theme="united" style="display:none;">
## Roadmap
This library is free, and will stay free but needs your support to sustain its development. There are lots of [**new features**](roadmap.html) and maintenance to do. If you work for a company using **doctest** or have the means to do so, please consider financial support.
[](http://www.patreon.com/onqtam)
[](https://www.paypal.me/onqtam/10)
Planned features for future releases - order changes constantly...
### For 1.3:
- move from printf to using streams in the current console reporter and clean that mess
- 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 - or maybe just an option for the console reporter
- an xml reporter
- xUnit reporter
- a listener interface - similar to a reporter - look at Catch
- ability to have no output when everything succeeds
- option to output summary only
- log levels - like in [boost test](http://www.boost.org/doc/libs/1_63_0/libs/test/doc/html/boost_test/utf_reference/rt_param_reference/log_level.html)
- matchers - should investigate what they are - look at google test/mock and Catch (also predicates and boost test)
- convolution support for the assertion macros (with a predicate)
- Value-Parameterized test cases
- generators? - look at Catch - and investigate what they are
- proper conan package
- https://github.com/uilianries/conan-catch
- https://github.com/philsquared/Catch/pull/938
- https://stackoverflow.com/questions/40311363/conan-io-header-only-package
- https://github.com/conan-io/docs/issues/67
- https://github.com/agauniyal/rang
- https://github.com/conan-io/conan/issues/324
- look at property based testing
- [rapidcheck](https://github.com/emil-e/rapidcheck)
- [autocheck](https://github.com/thejohnfreeman/autocheck)
- [CppQuickCheck](https://github.com/grogers0/CppQuickCheck)
- support for LibIdentify
- IDE integration
- https://blogs.msdn.microsoft.com/vcblog/2017/05/10/unit-testing-and-the-future-announcing-the-test-adapter-for-google-test/
- https://www.reddit.com/r/cpp/comments/65c0f1/run_cpp_unit_tests_from_xcode_and_visual_studio/
- https://github.com/k-brac/CUTI
- https://github.com/csoltenborn/GoogleTestAdapter
- MSTest
- 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
- https://blogs.msdn.microsoft.com/vcblog/2017/04/19/cpp-testing-in-visual-studio/
- https://msdn.microsoft.com/en-us/library/hh419385.aspx
- XCode - https://github.com/philsquared/Catch/pull/454
- CLion
- https://www.jetbrains.com/clion/features/unit-testing.html
- https://blog.jetbrains.com/clion/2017/03/clion-2017-1-released/#catch
### For 1.4:
- running tests a [few times](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.html#repeating-the-tests)
- test execution in [separate processes](https://github.com/philsquared/Catch/issues/853) - ```fork()``` for UNIX and [this](https://github.com/nemequ/munit/issues/2) for Windows
- killing a test that exceeds a time limit (will perhaps require threading or processes)
- [symbolizer](https://github.com/facebook/folly/tree/master/folly/experimental/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
- ability to make the framework not capture unexpected exceptions - as requested [here](https://github.com/onqtam/doctest/issues/12#issuecomment-235334585)
- add Approx ability to compare with absolute epsilon - [Catch PR](https://github.com/philsquared/Catch/pull/538)
- ability to customize the colors in the console output (may also use styles - based on [this](https://github.com/agauniyal/rang))
- implement breaking into the debugger under linux - see [here](https://github.com/philsquared/Catch/pull/585) and [here](https://github.com/scottt/debugbreak)
- better testing of the library
- unit test the String class
- should unit test internals - currently even if a bug is caught by different output it's very difficult to track the reason
- should test stuff that should not compile
- https://github.com/ldionne/dyno/blob/master/cmake/CompileFailTest.cmake
- see slide 38 here - https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_friday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf
- should test crash handling
- should test more config options
- don't cheat for maxing out code coverage (see [coverage_maxout.cpp](../../examples/all_features/coverage_maxout.cpp))
- should test C++11 stuff - perhaps inspect the CMAKE_CXX_FLAGS for -std=c++11 on the CI and add more targets/tests
- test tricky stuff like expressions with commas in asserts
### For 2.0:
- remove C++98 support
- remove the config identifiers for C++11 features
- use variadic templates where appropriate
- update type lists to C++11
- update traits - use declval, etc.
- move initialization of fields from initializer lists to class bodies
- update static code analysis - less warning suppressing
### For 3.0:
- use modules - use ```std::string``` and whatever else comes from the standard - no more hand rolled traits and classes
- minimize the use of the preprocessor
### Things that are being considered but not part of the roadmap yet:
- FakeIt mocking integration - like [catch](https://github.com/eranpeer/FakeIt/tree/master/config/catch)
- look into https://github.com/cpp-testing/GUnit - https://www.youtube.com/watch?v=NVrZjT5lW5o
- consider the following 2 properties for the MSVC static code analyzer: EnableCppCoreCheck, EnableExperimentalCppCoreCheck
- rpm package? like this: https://github.com/vietjtnguyen/argagg/blob/master/packaging/rpm/argagg.spec
- get the current test case/section path - https://github.com/philsquared/Catch/issues/522
- when no assertion is encountered in a test case it should fail
- failure reporting should print out previous SECTIONs for data-driven testing - as requested [here](https://github.com/philsquared/Catch/issues/734)
- ```Bitwise()``` class that has overloaded operators for comparison - to be used to check objects bitwise against each other
- detect floating point exceptions
- checkpoint/passpoint - like in [boost test](http://www.boost.org/doc/libs/1_63_0/libs/test/doc/html/boost_test/test_output/test_tools_support_for_logging/checkpoints.html) (also make all assert/subcase/logging macros to act as passpoints and print the last one on crashes or exceptions)
- queries for the current test case - name (and probably decorators)
- thread safety - asserts/subcases/captures should be safe to be used by multiple threads simultaneously
- support for running tests in parallel in multiple threads
- death tests - as in [google test](https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.html#death-tests)
- config options
- test case name uniqueness - reject the ones with identical names
- command line options
- ability to specify ASC/DESC for the order option
- global timeout option (per test or per entire session?)
- command line error handling/reporting
- option to not print context info when the --success option is used
- ability for the user to extend the command line - as requested [here](https://github.com/philsquared/Catch/issues/622)
- option to list files in which there are test cases who match the current filters
- option for filters to switch from "match any" to "match all" mode
- option to list test suites and test cases in a tree view
- add a "wait key" option - as requested [here](https://github.com/philsquared/Catch/issues/477#issuecomment-256417686)
- decorators for test cases and test suites- like in boost test
- depends_on
- precondition
- fixture
- label (tag) - with the ability to have multiple labels (tags) for a test case and also the ability to list them
- run X times (should also multiply with (or just override) the global test run times)
- throw an exception when incompatible decorators are given in the same list of decorators - like may_fail and should_fail
- setup / teardown support
- global setup / teardown - can be currently achieved by providing a custom main function
- per test suite (block? only? and not all blocks of the same test suite?)
- as decorators
- see how it's done in boost test - with the fixture decorator
- perhaps for fixtures in addition to the constructor / destructor - since throwing in the destructor might terminate the program
- or just ignore all of this this - it would require globals or classes and inheritance - and we already have subcases
- doctest in a GUI environment? with no console? APIs for attaching a console? querying if there is one? [investigate...](https://github.com/philsquared/Catch/blob/master/docs/configuration.html#stdout)
- runtime performance
- startup - the set holding all registered tests should use a specialized allocator to minimize program startup time
- failing - optimize createStream/freeStream to reuse a pool of ostringstream objects
- ability to provide a temp folder that is cleared between each test case
- make the _MESSAGE assert macros work with variadic arguments - and maybe write the ones for binary/unary/fast asserts as well
- move from operator "<<" to "<=" for capturing the left operand when decomposing binary expressions with templates
- think about silencing warnings about unused variables when DOCTEST_CONFIG_DISABLE is used - see commit 6b61e8aa3818c5ea100cedc1bb48a60ea10df6e8 or issue #61
- think about optionally using ```<typeinfo>``` and libcxxabi for demangling so users don't have to use ```TYPE_TO_STRING()```
- handle more complex expressions - ```CHECK(foo() == 1 || bar() == 2);```
- think about using a string view of some sorts
- benchmark against google test and boost test
### Things that are very unlikely to enter the roadmap:
- think about removing the binary asserts (leaving only the fast binary asserts) because normal asserts + no try/catch in asserts are almost the same
- move the "react()" part (the one that throws for REQUIRE asserts - or for when "abort-after=<int>" is reached) to a function call in the while() part of the asserts
- stop using underscores for the begining of identifiers - the anonymous variables - against the standard...
- templated fixture test cases
- test with missed warning flags for GCC
- https://github.com/Barro/compiler-warnings
- http://stackoverflow.com/a/34971392/3162383
- utf8 / unicode ???
- https://github.com/philsquared/Catch/pull/903
- handle ```wchar``` strings???
- hierarchical test suites - using a stack for the pushed ones
- ability to specify the width of the terminal in terms of characters (for example 60 - less than 80 - the default)
- 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**](https://github.com/nothings/stb) libraries can
---------------
[Home](readme.html#reference)
</xmp>
<script src="strapdown.js/strapdown.js"></script>
</html>
|
