Тестування

Учасники спільноти Rust зазвичай пишуть модульні тести у модулі, розміщеному у тому самому вхідному файлі, що й код, який тестується. Це було розглянуто раніше у курсі і має такий вигляд:

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

У Chromium ми розміщуємо модульні тести в окремому вхідному файлі і продовжуємо дотримуватися цієї практики для Rust --- це робить тести стабільно доступними для виявлення і допомагає уникнути повторної збірки .rs-файлів (у конфігурації test).

Це призводить до наступних варіантів тестування Rust-коду в Chromium:

  • Нативні тести Rust (тобто #[test]). Не рекомендується використовувати поза //third_party/rust.
  • Тести gtest, написані на C++, які виконують Rust за допомогою викликів FFI. Достатньо, коли код Rust є лише тонким прошарком FFI, а наявні модульні тести забезпечують достатнє покриття для функції.
  • Тести gtest, написані на Rust, що використовують крейт який тестується через його публічний API (з використанням pub mod for_testing { ... }, якщо потрібно). Це тема наступних кількох слайдів.

Зауважте, що нативне Rust-тестування сторонніх крейтів має зрештою здійснюватися ботами Chromium. (Таке тестування потрібне рідко --- лише після додавання або оновлення сторонніх крейтів).

Деякі приклади можуть допомогти проілюструвати, коли слід використовувати C++ gtest проти Rust gtest:

  • QR має дуже мало функціональності у сторонньому прошарку Rust (це просто тонкий FFI клей) і тому використовує існуючі модульні тести C++ для тестування як C++, так і Rust-реалізації (параметризуючи тести так, щоб вони вмикали або вимикали Rust за допомогою ScopedFeatureList).

  • Гіпотетична/WIP інтеграція з PNG може потребувати безпечної реалізації перетворень пікселів, які надаються libpng, але відсутні у крейті png - наприклад, RGBA => BGRA, або гамма-корекція. Така функціональність може отримати вигоду від окремих тестів, написаних у Rust.