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 (usando pub 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 crate png - por exemplo, RGBA => BGRA ou correção gama. Tal funcionalidade pode se beneficiar de testes separados escritos em Rust.