| commit | db758e027e735484d4e9b51da35ea737b0baec1d | [log] [tgz] |
|---|---|---|
| author | Stefan <29021710+Saalvage@users.noreply.github.com> | Mon Jun 06 03:42:02 2022 +0200 |
| committer | GitHub <noreply@github.com> | Mon Jun 06 03:42:02 2022 +0200 |
| tree | 6379443191e0e5214d3c139f5d9f4859c635b0dc | |
| parent | 16ed548bc973315a80497e51c2795d59b9dc5ac3 [diff] |
Add clang-tidy integration and fix all warnings (#659) * Add clang-tidy job * Install ninja * Remove duplicate path * Remove compiler specification?? * Remove linebreak * Readd compiler specification * Remove check specification * Install clang-tidy * Enable default checks * Add .clang-tidy * Start fixing tidy * Require tidy >=14 * Bump Ubuntu version * Bump clang-tidy invocation to 14 * Next set of fixes * Fix set :D * maybe this does the trick * ?? * ???? * Surely this is it * Close to just giving up * Mark operator* with noexcept * NOLINT * Bump clang-tidy version * Revert "Bump clang-tidy version" This reverts commit 3173050e17359eacd62899f284128ec2e0b4f5db. * More NOLINT test * Does this do the trick? * Else suppression * More fixes! * Specify error * Root cause * Readd at one location * Cleanup and more fixes * Huh! * More eradication * fuchsia * More fuchsia * More * definitions-in-headers * definitions-in-headers 2 * Does this do the trick? * Sussy lambda cast * Mem * Try default move const * Improve declaration * A lot more fixes! * - * + * * * Getting somewhere * Woo * More * Fix process * Update main.yml * Update main.yml * Update main.yml * Update main.yml * Wrap up and add all CI * Accomodate weird DLL bug? * Update main.yml * Test reintroduce error * Finishing touches * Final finishing touches
- .clang-tidy[Added - diff]
- .github/workflows/main.yml[diff]
- doctest/doctest.h[diff]
- doctest/parts/doctest.cpp[diff]
- doctest/parts/doctest_fwd.h[diff]
- examples/all_features/CMakeLists.txt[diff]
- examples/all_features/assert_returns_disabled.cpp[diff]
- examples/all_features/assertion_macros.cpp[diff]
- examples/all_features/coverage_maxout.cpp[Renamed from scripts/coverage_maxout.cpp - diff]
- examples/all_features/decomposition.cpp[diff]
- examples/all_features/enums.cpp[diff]
- examples/all_features/header.h[diff]
- examples/all_features/logging.cpp[diff]
- examples/all_features/main.cpp[diff]
- examples/all_features/stringification.cpp[diff]
- examples/all_features/subcases.cpp[diff]
- examples/all_features/templated_test_cases.cpp[diff]
- examples/combining_the_same_tests_built_differently_in_multiple_shared_objects/foo.h[diff]
- examples/exe_with_static_libs/lib_1_src1.cpp[diff]
- examples/exe_with_static_libs/lib_1_src2.cpp[diff]
- examples/exe_with_static_libs/lib_2_src.cpp[diff]
- examples/exe_with_static_libs/main.cpp[diff]
- examples/executable_dll_and_plugin/implementation.cpp[diff]
- examples/executable_dll_and_plugin/implementation_2.cpp[diff]
- examples/executable_dll_and_plugin/main.cpp[diff]
- .clang-format
- .clang-tidy
- .editorconfig
- .gitattributes
- .github/
- .gitignore
- CHANGELOG.md
- CMakeLists.txt
- CONTRIBUTING.md
- LICENSE.txt
- README.md
- WORKSPACE
- doc/
- doctest/
- examples/
- meson.build
- scripts/
doctest is a new C++ testing framework but is by far the fastest both in compile times (by orders of magnitude) and runtime compared to other feature-rich alternatives. It brings the ability of compiled languages such as D / Rust / Nim to have tests written directly in the production code thanks to a fast, transparent and flexible test runner with a clean interface.
The framework is 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. Monthly donations via Patreon and one-offs via PayPal.
A complete example with a self-registering test that compiles to an executable looks like this:
There are many C++ testing frameworks - Catch, Boost.Test, UnitTest++, cpputest, googletest and others.
The key differences between it and other testing frameworks are that it is light and unintrusive:
- Ultra light on compile times both in terms of including the header and writing thousands of asserts
- Doesn't produce any warnings even on the most aggressive warning levels for MSVC/GCC/Clang
- Can remove everything testing-related from the binary with the
DOCTEST_CONFIG_DISABLEidentifier - thread-safe - asserts can be used from multiple threads spawned from a single test case - example
- asserts can be used outside of a testing context - as a general purpose assert library - example
- No global namespace pollution (everything is in
doctest::) & doesn't drag any headers with it - Portable C++11 (use tag 1.2.9 for C++98) with over 100 different CI builds (static analysis, sanitizers..)
- binaries (exe/dll) can use the test runner of another binary => tests in a single registry - example
This allows the framework to be used in more ways than any other - tests can be written directly in the production code!
Tests can be a form of documentation and should be able to reside near the production code which they test.
- This makes the barrier for writing tests much lower - you don't have to: 1) make a separate source file 2) include a bunch of stuff in it 3) add it to the build system and 4) add it to source control - You can just write the tests for a class or a piece of functionality at the bottom of its source file - or even header file!
- Tests in the production code can be thought of as documentation/up-to-date comments - showcasing the APIs
- Testing internals that are not exposed through the public API and headers is no longer a mind-bending exercise
- Test-driven development in C++ has never been easier!
The framework can be used just like any other without mixing production code and tests - check out the features.
doctest is modeled after Catch and some parts of the code have been taken directly - check out the differences.
This table compares doctest / Catch / lest which are all very similar.
Checkout the CppCon 2017 talk on YouTube to get a better understanding of how the framework works and read about how to use it in the JetBrains article - highlighting the unique aspects of the framework! On a short description on how to use the framework along production code you could refer to this GitHub issue. There is also an older article in the february edition of ACCU Overload 2017.
Documentation
Project:
- Features and design goals - the complete list of features
- Community driven roadmap - upcoming features
- Benchmarks - compile-time and runtime supremacy
- Contributing - how to make a proper pull request
- Changelog - generated changelog based on closed issues/PRs
Usage:
- Tutorial - make sure you have read it before the other parts of the documentation
- Assertion macros
- Test cases, subcases and test fixtures
- Parameterized test cases
- Command line
- Logging macros
main()entry point- Configuration
- String conversions
- Reporters
- Extensions
- FAQ
- Build systems
- Examples
Contributing
Support the development of the project with donations! There is a list of planned features which are all important and big - see the roadmap.
If you work for a company using doctest or have the means to do so, please consider financial support.
Contributions in the form of issues and pull requests are welcome as well - check out the Contributing page.
Stargazers over time
Logo
The logo is licensed under a Creative Commons Attribution 4.0 International License. Copyright © 2019 area55git 