Testes
A comunidade Rust normalmente escreve testes unitários em um módulo colocado no mesmo arquivo de código sendo testado. Isso foi abordado anteriormente no curso e se parece com isso:
#![allow(unused)] fn main() { #[cfg(test)] mod tests { #[test] fn my_test() { todo!() } } }
No Chromium, colocamos os testes unitários em um arquivo de código separado e continuamos a seguir essa prática para o Rust --- isso torna os testes consistentemente descobríveis e ajuda a evitar a reconstrução de arquivos .rs
uma segunda vez (na configuração test
).
Isto resulta nas seguintes opções para testar código Rust no Chromium:
- Testes nativos Rust (ou seja,
#[test]
). Desencorajado fora de//third_party/rust
. - Testes
gtest
escritos em C++ e exercitando Rust via chamadas FFI. Suficiente quando o código Rust é apenas uma camada FFI fina e os testes unitários existentes fornecem cobertura suficiente para o recurso. - Testes
gtest
escritos em Rust e usando o crate sob teste por meio de sua API pública (usandopub mod for_testing { ... }
se necessário). Este é o assunto dos próximos slides.
Mencione que os testes nativos Rust de crates de terceiros devem eventualmente ser exercitados pelos robôs do Chromium. (Esses testes são raramente necessários --- apenas após adicionar ou atualizar crates de terceiros.)
Alguns exemplos podem ajudar a ilustrar quando o gtest
C++ vs Rust gtest
deve ser usado:
-
QR tem muito pouca funcionalidade na camada Rust original (é apenas uma cola FFI fina) e, portanto, usa os testes unitários C++ existentes para testar tanto a implementação C++ quanto a Rust (parametrizando os testes para que eles ativem ou desativem o Rust usando um
ScopedFeatureList
). -
A integração hipotética/em andamento do PNG pode precisar de uma implementação segura de memória das transformações de pixels fornecidas pelo
libpng
, mas ausentes no cratepng
- por exemplo, RGBA => BGRA ou correção gama. Tal funcionalidade pode se beneficiar de testes separados escritos em Rust.