Adjust test/README.md instructions for cmake

I've included the configuration and compilation in the recommended commands to simplify the user's very first steps.

src/test/README.md

@@ -6,34 +6,40 @@ 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 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
-`util/setup_common.cpp`.
+The build system is set up to compile an executable called `test_bitcoin` that runs all the unit tests.
+The main source file for the test library is found in `util/setup_common.cpp`.
 
 ### Compiling/running unit tests
 
-Unit tests will be automatically compiled if dependencies were met in `./configure`
-and tests weren't explicitly disabled.
+Unit tests will be automatically compiled if the dependencies are met
+during the generation of the Bitcoin Core build system.
+To configure the project, build it in the 'build' directory, and then run all unit tests, execute the following:
 
-After configuring, they can be run with `make check`, which includes unit tests from
-subtrees, or `make && make -C src check-unit` for just the unit tests.
-
-To run the unit tests manually, launch `src/test/test_bitcoin`. To recompile
-after a test file was modified, run `make` and then run the test again. If you
-modify a non-test file, use `make -C src/test` to recompile only what's needed
-to run the unit tests.
+```bash
+cmake -B build
+cmake --build build    # use "-j N" for N parallel jobs
+ctest --test-dir build # use "-j N" for N parallel jobs
+```
 
 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 run the GUI unit tests manually, launch `src/qt/test/test_bitcoin-qt`
+To run the GUI unit tests manually, launch `build/src/qt/test/test_bitcoin-qt`
 
 To add more GUI unit tests, add them to the `src/qt/test/` directory and
 the `src/qt/test/test_main.cpp` file.
 
 ### Running individual tests
 
+To manually run a specific unit test (e.g., `bech32_testvectors_valid` in `bech32_tests.cpp`),
+use the following commands:
+
+```bash
+cmake --build build --target src/test/test_bitcoin # use "-j N" for N parallel jobs
+build/src/test/test_bitcoin --run_test=bech32_tests/bech32_testvectors_valid
+```
+
 `test_bitcoin` accepts the command line arguments from the boost framework.
 For example, to run just the `getarg_tests` suite of tests:
 
@@ -44,23 +50,17 @@ test_bitcoin --log_level=all --run_test=getarg_tests
 `log_level` controls the verbosity of the test framework, which logs when a
 test case is entered, for example.
 
-`test_bitcoin` also accepts some of the command line arguments accepted by
-`bitcoind`. Use `--` to separate these sets of arguments:
+`test_bitcoin` also accepts some of the command line arguments accepted by `bitcoind`.
+Use `--` to separate these sets of arguments:
 
 ```bash
-test_bitcoin --log_level=all --run_test=getarg_tests -- -printtoconsole=1
+build/src/test/test_bitcoin --log_level=all --run_test=getarg_tests -- -printtoconsole=1
 ```
 
 The `-printtoconsole=1` after the two dashes sends debug logging, which
 normally goes only to `debug.log` within the data directory, also to the
 standard terminal output.
 
-... or to run just the doubledash test:
-
-```bash
-test_bitcoin --run_test=getarg_tests/doubledash
-```
-
 `test_bitcoin` creates a temporary working (data) directory with a randomly
 generated pathname within `test_common_Bitcoin Core/`, which in turn is within
 the system's temporary directory (see
@@ -81,7 +81,7 @@ what the test wrote to `debug.log` after it completes, for example.
 so no leftover state is used.)
 
 ```bash
-$ test_bitcoin --run_test=getarg_tests/doubledash -- -testdatadir=/somewhere/mydatadir
+$ build/src/test/test_bitcoin --run_test=getarg_tests/doubledash -- -testdatadir=/somewhere/mydatadir
 Test directory (will not be deleted): "/somewhere/mydatadir/test_common_Bitcoin Core/getarg_tests/doubledash/datadir
 Running 1 test case...
 
@@ -117,17 +117,17 @@ on failure. For running individual tests verbosely, refer to the section
 To write to logs from unit tests you need to use specific message methods
 provided by Boost. The simplest is `BOOST_TEST_MESSAGE`.
 
-For debugging you can launch the `test_bitcoin` executable with `gdb` or `lldb` and
+For debugging, you can launch the `test_bitcoin` executable with `gdb` or `lldb` and
 start debugging, just like you would with any other program:
 
 ```bash
-gdb src/test/test_bitcoin
+gdb build/src/test/test_bitcoin
 ```
 
 #### Segmentation faults
 
 If you hit a segmentation fault during a test run, you can diagnose where the fault
-is happening by running `gdb ./src/test/test_bitcoin` and then using the `bt` command
+is happening by running `gdb ./build/src/test/test_bitcoin` and then using the `bt` command
 within gdb.
 
 Another tool that can be used to resolve segmentation faults is
@@ -145,7 +145,7 @@ Running the tests and hitting a segmentation fault should now produce a file cal
 
 You can then explore the core dump using
 ```bash
-gdb src/test/test_bitcoin core
+gdb build/src/test/test_bitcoin core
 
 (gbd) bt  # produce a backtrace for where a segfault occurred
 ```