Bitcoin Core リポジトリのユニットテスト
ビットコインコアの統合/ステージングツリー。開発プロセス master ブランチは定期的にビルドされ (手順については doc/build-*.md を参照)、テストされますが、完全に安定しているという保証はありません。
ひと目でわかる
- これは何？
- test_bitcoin ランナーの使い方、テストの実行とフィルタリング、新しいテストケースの追加方法。
- 誰に向いている？
- Bitcoin Core の C++ テストを追加・絞り込みしたい開発者にとって、test_bitcoin の README は具体的な入口です。ノード全体の動作保証やネットワーク試験をこのランナーだけで代用するものではありません。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に C++ です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
test_bitcoin が担う確認範囲
src/test/README.md は、Bitcoin Core リポジトリのユニットテストスイートのドキュメントです。テストコードの配置場所、テストランナーのビルド方法、実行方法、新しいテストの追加方法が説明されています。リポジトリのメタデータは、このプロジェクトを Bitcoin Core の統合およびステージングツリーであり、言語は C++ としています。この README は Bitcoin Core コードベースの他の部分を扱っていないため、ユニットテストのワークフロー以外の内容はこの記事の範囲外です。
ビルド後にテストを起動する
ビルドシステムは、すべてのユニットテストを実行する test_bitcoin という実行ファイルをコンパイルします。テストライブラリのメインソースファイルは util/setup_common.cpp です。ビルドシステムの生成時に依存関係が満たされ、テストが明示的に無効化されていない場合、ユニットテストは自動的にコンパイルされます。すべてのユニットテストを実行するには、ctest --test-dir build を使用します。これにはサブツリーのユニットテストも含まれます。テストの全一覧は build/bin/test_bitcoin --list_content で確認できます。テストファイルを変更した後は、cmake --build build を実行してからテストを再度実行します。非テストファイルを変更した場合は、cmake --build build --target test_bitcoin を使用すると、ユニットテストの実行に必要な部分だけが再コンパイルされます。例ではビルドディレクトリ名が build であることを前提としています。
Boost のフィルタで対象を絞る
test_bitcoin ランナーは、Boost フレームワークのコマンドライン引数を受け入れます。利用可能な引数は build/bin/test_bitcoin --help で確認できます。たとえば、getarg_tests ファイルのテストだけを完全なログ付きで実行するには、--log_level=all --run_test=getarg_tests を使うか、短縮形の -l all -t getarg_tests を使います。getarg_tests/doubledash のように、単一のテストを指定することもできます。ランナーは、-- の区切り記号の後ろに bitcoind の引数の一部も受け入れます。たとえば、-- -printtoconsole=1 を指定すると、通常はデータディレクトリ内の debug.log にのみ書き込まれるデバッグログが、ターミナル出力にも送信されます。--log_level または -l 引数は、テスト出力の詳細度を制御します。
一時データディレクトリを読む
test_bitcoin を実行すると、システムの一時ディレクトリ内の test_common bitcoin/ の中に、ランダムに生成されたパス名を持つ一時作業データディレクトリが作成されます。このデータディレクトリは、標準の bitcoind データディレクトリを簡略化した形をしており、常に debug.log が含まれます。場所は -testdatadir で指定できます。使用されるディレクトリは、引数のパスに /test_common bitcoin/<test-name>/datadir を追加したもので、必要に応じて作成されます。この引数を指定すると、データディレクトリは最後のテスト後に削除されないため、デバッグが容易になります。次のテスト実行の開始時に削除されるため、残った状態は使われません。テストスイート全体またはすべてのスイートを実行する場合、個々のテストごとに別々のディレクトリが作成されます。
BOOST_AUTO_TEST_CASE の追加
ユニットテストを追加するには、test/ ディレクトリの既存の .cpp ファイルに BOOST_AUTO_TEST_CASE 関数を追加するか、BOOST_AUTO_TEST_SUITE セクションを実装する新しい .cpp ファイルを追加します。新しいテストファイルは src/test/CMakeLists.txt にリストする必要があります。ウォレット関連のテストの場合は src/wallet/test/CMakeLists.txt です。慣例として、テストしたいクラスまたはソースファイルごとに 1 つのテストファイルを作成し、<source_filename>_tests.cpp という命名規則に従い、テストスイートも <source_filename>_tests と名付けます。README は uint256_tests.cpp を例として挙げています。GUI ユニットテストは src/qt/test/ ディレクトリと src/qt/test/test_main.cpp ファイルに追加し、build/bin/test_bitcoin-qt で実行します。
失敗時に見るログと前提
ctest --test-dir build は、build/Testing/Temporary/LastTest.log にログを書き込みます。--output-on-failure オプションを使うと、失敗したテストのログを自動的に表示できます。ユニットテストからログを書き込むには、Boost が提供するメッセージメソッド、最も簡単なのは BOOST_TEST_MESSAGE を使用します。デバッグには、他のプログラムと同様に gdb または lldb で test_bitcoin を起動できます。セグメンテーションフォールトが発生した場合は、gdb build/bin/test_bitcoin を実行し、gdb 内で bt コマンドを使ってバックトレースを確認します。valgrind も役立ちます。デフォルトでは Boost テストランナーはシステムエラーをインターセプトするため、コアファイルは生成されません。コアダンプを生成するには、test_bitcoin の引数に --catch_system_errors=no を追加し、ulimit を適切に設定します。生成された core ファイルは、gdb build/bin/test_bitcoin core で調べられます。
Bitcoin Core 本体との距離
リポジトリのメタデータには、SPDX ライセンス識別子として MIT が記録されており、プロジェクトは Bitcoin Core の統合およびステージングツリーと説明されています。提供されたメタデータに付属するライセンス抜粋には、一般的なパスに LICENSE ファイルが見つからなかったと記載されています。そのため、実際のライセンステキストは提供された素材には含まれておらず、この記事はそのライセンスが何を許諾し、何を要求するかを述べることができません。README 自体もライセンスには言及していません。ライセンスを確認するには、リポジトリのルートにある LICENSE ファイルを調べ、そのテキストと SPDX 識別子を照合してください。
編集部の結論
Bitcoin Core の C++ テストを追加・絞り込みしたい開発者にとって、test_bitcoin の README は具体的な入口です。ノード全体の動作保証やネットワーク試験をこのランナーだけで代用するものではありません。最初にビルド済みバイナリで既存テストを実行し、一時ディレクトリと Boost のフィルタ結果を確認してください。
コミュニティノート