Testing
Rust community typically authors unit tests in a module placed in the same source file as the code being tested. This was covered earlier in the course and looks like this:
1. ```
#![allow(unused)]
```
2. ```
fn main() {
```
3. ```
#[cfg(test)]
```
4. ```
mod tests {
```
5. ```
#[test]
```
6. ```
fn my_test() {
```
7. ```
todo!()
```
8. ```
}
```
9. ```
}
```
10. ```
}
```
In Chromium we place unit tests in a separate source file and we continue to follow this practice for Rust —- this makes tests consistently discoverable and helps to avoid rebuilding .rs files a second time (in the test configuration).
This results in the following options for testing Rust code in Chromium:
- Native Rust tests (i.e.
#[test]). Discouraged outside of//third_party/rust. gtesttests authored in C++ and exercising Rust via FFI calls. Sufficient when Rust code is just a thin FFI layer and the existing unit tests provide sufficient coverage for the feature.gtesttests authored in Rust and using the crate under test through its public API (usingpub mod for_testing { ... }if needed). This is the subject of the next few slides.
Mention that native Rust tests of third-party crates should eventually be exercised by Chromium bots. (Such testing is needed rarely —- only after adding or updating third-party crates.)
Some examples may help illustrate when C++ gtest vs Rust gtest should be used:
- QR has very little functionality in the first-party Rust layer (it’s just a thin FFI glue) and therefore uses the existing C++ unit tests for testing both the C++ and the Rust implementation (parameterizing the tests so they enable or disable Rust using a
ScopedFeatureList). - Hypothetical/WIP PNG integration may need to implement memory-safe implementation of pixel transformations that are provided by
libpngbut missing in thepngcrate - e.g. RGBA => BGRA, or gamma correction. Such functionality may benefit from separate tests authored in Rust.
