Тестування
Учасники спільноти 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.