Remove remaining BOOST references

Author: rustaceanrob

doc/developer-notes.md

@@ -49,7 +49,7 @@ code.
     naming style](#internal-interface-naming-style) for an exception to this
     convention.
 
-  - Test suite naming convention: The Boost test suite in file
+  - Test suite naming convention: The test suite in file
     `src/test/foo_tests.cpp` should be named `foo_tests`. Test suite names
     must be unique.
 

src/test/README.md

@@ -1,10 +1,11 @@
 # Unit tests
 
-The sources in this directory are unit test cases. Boost includes a
-unit testing framework, and since Bitcoin Core already uses Boost, it makes
-sense to simply use this framework rather than require developers to
-configure some other framework (we want as few impediments to creating
-unit tests as possible).
+The sources in this directory are unit test cases. Tests use a small
+header-only framework declared in `src/test/util/framework.hpp`, which
+provides registration macros (`TEST_CASE`, `FIXTURE_TEST_CASE`,
+`TEST_SUITE_BEGIN`/`TEST_SUITE_END`) and assertion macros (`CHECK`,
+`REQUIRE`, `CHECK_THROWS`, `CHECK_THROWS_AS`, `CHECK_EXCEPTION`,
+`CHECK_EQUAL_RANGES`, `TEST_MESSAGE`, `WARN_MESSAGE`).
 
 The build system is set up to compile an executable called `test_bitcoin`
 that runs all of the unit tests. The main source file for the test library is found in
@@ -22,27 +23,26 @@ and tests weren't explicitly disabled.
 The unit tests can be run with `ctest --test-dir build`, which includes unit
 tests from subtrees.
 
-Run `build/bin/test_bitcoin --list_content` for the full list of tests.
+Run `build/bin/test_bitcoin --list` for the full list of tests.
 
 To run the unit tests manually, launch `build/bin/test_bitcoin`. To recompile
 after a test file was modified, run `cmake --build build` and then run the test again. If you
 modify a non-test file, use `cmake --build build --target test_bitcoin` to recompile only what's needed
 to run the unit tests.
 
-To add more unit tests, add `BOOST_AUTO_TEST_CASE` functions to the existing
-.cpp files in the `test/` directory or add new .cpp files that
-implement new `BOOST_AUTO_TEST_SUITE` sections.
+To add more unit tests, add `TEST_CASE` (or `FIXTURE_TEST_CASE`) functions to
+the existing .cpp files in the `test/` directory, or add new .cpp files that
+declare a new suite with `TEST_SUITE_BEGIN("<name>")`.
 
 ### Running individual tests
 
-The `test_bitcoin` runner accepts command line arguments from the Boost
-framework. To see the list of arguments that may be passed, run:
+To see the list of arguments that may be passed, run:
 
 ```
 build/bin/test_bitcoin --help
 ```
 
-For example, to run only the tests in the `getarg_tests` file, with full logging:
+For example, to run only the tests in the `getarg_tests` suite, with full logging:
 
 ```bash
 build/bin/test_bitcoin --log_level=all --run_test=getarg_tests
@@ -54,13 +54,14 @@ or
 build/bin/test_bitcoin -l all -t getarg_tests
 ```
 
-or to run only the doubledash test in `getarg_tests`
+or to run only the `doubledash` test in `getarg_tests`
 
 ```bash
-build/bin/test_bitcoin --run_test=getarg_tests/doubledash
+build/bin/test_bitcoin --run_test=getarg_tests::doubledash
 ```
 
 The `--log_level=` (or `-l`) argument controls the verbosity of the test output.
+Accepted values: `none`, `error` (default), `info`, `all`.
 
 The `test_bitcoin` runner also accepts some of the command line arguments accepted by
 `bitcoind`. Use `--` to separate these sets of arguments:
@@ -126,8 +127,10 @@ additionally use the `--output-on-failure` option to display logs of the failed
 on failure. For running individual tests verbosely, refer to the section
 [above](#running-individual-tests).
 
-To write to logs from unit tests you need to use specific message methods
-provided by Boost. The simplest is `BOOST_TEST_MESSAGE`.
+To write a diagnostic message from a unit test, use `TEST_MESSAGE(...)`
+(emitted at log level `info` or higher). `WARN_MESSAGE(cond, msg)` emits
+a warning when `cond` is false without failing the test — use `CHECK` /
+`REQUIRE` to fail.
 
 For debugging you can launch the `test_bitcoin` executable with `gdb` or `lldb` and
 start debugging, just like you would with any other program:
@@ -146,13 +149,9 @@ Another tool that can be used to resolve segmentation faults is
 [valgrind](https://valgrind.org/).
 
 If for whatever reason you want to produce a core dump file for this fault, you can do
-that as well. By default, the boost test runner will intercept system errors and not
-produce a core file. To bypass this, add `--catch_system_errors=no` to the
-`test_bitcoin` arguments and ensure that your ulimits are set properly (e.g. `ulimit -c
-unlimited`).
-
-Running the tests and hitting a segmentation fault should now produce a file called `core`
-(on Linux platforms, the file name will likely depend on the contents of
+that as well. Ensure that your ulimits are set properly (e.g. `ulimit -c unlimited`),
+then running the tests and hitting a segmentation fault should produce a file called
+`core` (on Linux platforms, the file name will likely depend on the contents of
 `/proc/sys/kernel/core_pattern`).
 
 You can then explore the core dump using

src/test/btcsignals_tests.cpp

@@ -160,8 +160,8 @@ FIXTURE_TEST_CASE(thread_safety, BasicTestingSetup)
             sig0();
         }
         // Because these calls are purposely happening on both threads at the
-        // same time, these must be asserts rather than BOOST_CHECKs to prevent
-        // a race inside of BOOST_CHECK itself (writing to the log).
+        // same time, these must be asserts rather than CHECKs to prevent
+        // a race inside of CHECK itself (writing to the log).
         assert(!sig0.empty());
         assert(conn0.connected());
     });

src/test/cuckoocache_tests.cpp

@@ -25,8 +25,8 @@
  *  3. Results should be treated as a regression test, i.e., did the behavior
  *  change significantly from what was expected. This can be OK, depending on
  *  the nature of the change, but requires updating the tests to reflect the new
- *  expected behavior. For example improving the hit rate may cause some tests
- *  using BOOST_CHECK_CLOSE to fail.
+ *  expected behavior. For example improving the hit rate may cause some
+ *  tolerance-based checks to fail.
  *
  */
 TEST_SUITE_BEGIN(cuckoocache_tests);

src/test/descriptor_tests.cpp

@@ -283,10 +283,8 @@ void DoCheck(std::string prv, std::string pub, const std::string& norm_pub, int
     CHECK(parse_priv->IsRange() == ((flags & RANGE) != 0));
 
     // Check that the highest key expression index matches the number of keys in the descriptor
-    /* BOOST_TEST_INFO("Pub desc: " + pub) */;
     uint32_t key_exprs = parse_pub->GetMaxKeyExpr();
     CHECK(key_exprs + 1 == parse_pub->GetKeyCount());
-    /* BOOST_TEST_INFO("Priv desc: " + prv) */;
     CHECK(key_exprs == parse_priv->GetMaxKeyExpr());
     CHECK(key_exprs + 1 == parse_priv->GetKeyCount());
 

src/test/logging_tests.cpp

@@ -395,14 +395,12 @@ void TestLogFromLocation(Location location, const std::string& message,
                          BCLog::LogRateLimiter::Status status, bool suppressions_active,
                          std::source_location source = std::source_location::current())
 {
-    /* BOOST_TEST_INFO_SCOPE("TestLogFromLocation called from " << source.file_name() << ":" << source.line()) */;
     using Status = BCLog::LogRateLimiter::Status;
     if (!suppressions_active) assert(status == Status::UNSUPPRESSED); // developer error
 
     std::ofstream ofs(LogInstance().m_file_path.std_path(), std::ios::out | std::ios::trunc); // clear debug log
     LogFromLocation(location, message);
     auto log_lines{ReadDebugLogLines()};
-    /* BOOST_TEST_INFO_SCOPE(log_lines.size() << " log_lines read: \n" << util::Join(log_lines, "\n")) */;
 
     if (status == Status::STILL_SUPPRESSED) {
         CHECK(log_lines.size() == 0U);

src/test/util/common.h

@@ -11,7 +11,7 @@
 #include <string>
 
 /**
- * BOOST_CHECK_EXCEPTION predicates to check the specific validation error.
+ * Predicate to check the specific validation error.
  * Use as
  * CHECK_EXCEPTION(code that throws, exception type, HasReason("foo"));
  */
@@ -26,7 +26,7 @@ class HasReason
     const std::string m_reason;
 };
 
-// Make types usable in BOOST_CHECK_* @{
+// Make types usable in CHECK / REQUIRE @{
 namespace std {
 template <typename Clock, typename Duration>
 inline std::ostream& operator<<(std::ostream& os, const std::chrono::time_point<Clock, Duration>& tp)

src/test/versionbits_tests.cpp

@@ -373,7 +373,7 @@ void check_computeblockversion(VersionBitsCache& versionbitscache, const Consens
     }
 
     if (nTimeout != Consensus::BIP9Deployment::NO_TIMEOUT) {
-        // can reach any nTimeout other than NO_TIMEOUT due to earlier BOOST_REQUIRE
+        // can reach any nTimeout other than NO_TIMEOUT due to earlier REQUIRE
 
         nTime = nTimeout;
 

test/lint/test_runner/src/lint_cpp.rs

@@ -195,7 +195,7 @@ pub fn lint_boost_assert() -> LintResult {
         .success();
     if found {
         Err(r#"
-BOOST_ASSERT must be replaced with Assert, BOOST_REQUIRE, or BOOST_CHECK to avoid an unnecessary
+BOOST_ASSERT must be replaced with Assert, REQUIRE, or CHECK to avoid an unnecessary
 include of the boost/assert.hpp dependency.
             "#
         .trim()
@@ -204,3 +204,35 @@ include of the boost/assert.hpp dependency.
         Ok(())
     }
 }
+
+pub fn lint_boost_test() -> LintResult {
+    let found = git()
+        .args([
+            "grep",
+            "--line-number",
+            "--extended-regexp",
+            r"BOOST_(AUTO_TEST_|FIXTURE_TEST_|GLOBAL_FIXTURE|DATA_TEST_|CHECK|REQUIRE|TEST|WARN)",
+            "--",
+            "*.cpp",
+            "*.h",
+            // src/univalue is a subtree (not tracked in get_subtrees()); its tests use Boost.Test independently.
+            ":(exclude)src/univalue",
+        ])
+        .args(get_pathspecs_default_excludes())
+        .status()
+        .expect("command error")
+        .success();
+    if found {
+        Err(r#"
+Boost.Test macros (BOOST_CHECK*, BOOST_REQUIRE*, BOOST_AUTO_TEST_*, BOOST_FIXTURE_TEST_*,
+BOOST_TEST*, BOOST_WARN*, BOOST_GLOBAL_FIXTURE, BOOST_DATA_TEST_*) are no longer used.
+Replace with the equivalents from src/test/util/framework.hpp (CHECK, REQUIRE, TEST_CASE,
+FIXTURE_TEST_CASE, TEST_SUITE_BEGIN, CHECK_THROWS, CHECK_THROWS_AS, CHECK_EXCEPTION,
+TEST_MESSAGE, WARN_MESSAGE, etc.).
+            "#
+        .trim()
+        .to_string())
+    } else {
+        Ok(())
+    }
+}

test/lint/test_runner/src/main.rs

@@ -14,8 +14,8 @@ use std::fs;
 use std::process::{Command, ExitCode};
 
 use lint_cpp::{
-    lint_boost_assert, lint_includes_build_config, lint_remove_all, lint_rpc_assert,
-    lint_std_filesystem,
+    lint_boost_assert, lint_boost_test, lint_includes_build_config, lint_remove_all,
+    lint_rpc_assert, lint_std_filesystem,
 };
 use lint_docs::{lint_doc_args, lint_doc_release_note_snippets, lint_markdown};
 use lint_py::lint_py_lint;
@@ -73,6 +73,11 @@ fn get_linter_list() -> Vec<&'static Linter> {
             name: "boost_assert",
             lint_fn: lint_boost_assert
         },
+        &Linter {
+            description: "Check that Boost.Test macros are not used (use src/test/util/framework.hpp)",
+            name: "boost_test",
+            lint_fn: lint_boost_test
+        },
         &Linter {
             description: "Check that release note snippets are in the right folder",
             name: "doc_release_note_snippets",