テスト

Rust コミュニティでは通常、ユニットテストはテスト対象のコードと同じソースファイル内に置かれたモジュールとして記述します。これはコースの前半で説明したとおりで、次のようになります:

#![allow(unused)]
fn main() {
// Copyright 2023 Google LLC
// SPDX-License-Identifier: Apache-2.0

#[cfg(test)]
mod tests {
    #[test]
    fn my_test() {
        todo!()
    }
}
}

Chromium では、ユニットテストを別のソースファイルに配置しており、Rust でもこの慣行を引き続き採用します — これによりテストを一貫して見つけやすくなり、 .rs ファイルを 2 回目に再ビルドすること（test 構成で）を避けるのに役立ちます。

その結果、Chromium で Rust コードをテストする方法として、次の選択肢があります:

ネイティブな Rust テスト（つまり #[test]）。//third_party/rust の外では推奨されません。
C++ で記述し、FFI 呼び出しを介して Rust をテストする gtest テスト。Rust コードが単なる薄い FFI レイヤーであり、既存のユニットテストがその機能を十分にカバーしている場合には、これで十分です。
Rust で記述し、テスト対象のクレートをその公開 API 経由で使用する gtest テスト（必要に応じて pub mod for_testing { ... } を使用）。これが次の数枚のスライドのテーマです。

サードパーティ製クレートのネイティブな Rust テストは、最終的には Chromium ボットで実行されるべきであることに言及してください。（この種のテストが必要になるのはまれで、サードパーティ製クレートを追加または更新した後だけです。）

C++ gtest と Rust gtest のどちらを使うべきかを示すには、いくつかの例が役立つかもしれません:

QR はファーストパーティの Rust レイヤーにほとんど機能がなく（単なる薄い FFI グルーにすぎません）、そのため既存の C++ ユニットテストを使って C++ 実装と Rust 実装の両方をテストします（テストをパラメータ化し、 ScopedFeatureList を使って Rust を有効化または無効化できるようにします）。
仮想的な / 作業中の PNG 統合では、libpng にはあるものの png クレートにはないピクセル変換のメモリ安全な実装が必要になるかもしれません - たとえば RGBA => BGRA やガンマ補正です。このような機能は、Rust で記述した個別のテストの恩恵を受ける可能性があります。

Comprehensive Rust 🦀

テスト