Testando

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.