Boas Práticas de Testes

Q: Doctests na CI?

cargo test --doc --workspace no PR se a documentação faz parte do contrato da API.

Q: Como testar CLI?

assert_cmd ou snapshot de --help; integração com diretórios temporários para saída de arquivo.

Testes rápidos, determinísticos e significativos dão às equipes Rust confiança para refatorar sem falhas na CI ou duplicação de incidentes de produção.

Como Usar Esta Lista

Aplique ao adicionar um crate ou revisar lacunas de teste após um incidente.
Use como checklist de PR para novos recursos (unitário + integração + documentação onde for público).
Combine com Cobertura e CI para aplicação no pipeline.

A - Estrutura

Coloque testes unitários em #[cfg(test)] mod tests. API privada testada ao lado da implementação.
Testes de integração em tests/ por área de comportamento. Um arquivo por recurso, não um mega-arquivo.
Extraia a biblioteca do binário para testabilidade. main enxuto, lib robusto.
Compartilhe fixtures em tests/common/. Sem copiar e colar configuração de HTTP/DB.
Doctests em exemplos de API pública. Mantenha o rustdoc honesto (Doctests).

B - Determinismo

Sem rede real ou banco de dados de produção no cargo test padrão. Mocks, fakes ou testcontainers atrás de #[ignore].
Use tokio::time::pause em vez de sleep em testes assíncronos. Tempo mais rápido e determinístico.
Isole estado global ou use serial_test. Testes paralelos não devem compartilhar mut statics.
Redija timestamps/UUIDs em snapshots. Arquivos de ouro estáveis (Snapshot Testing).
Semeie testes de propriedade; comite proptest-regressions. Falhas reproduzíveis.

C - Qualidade

Afirme o comportamento, não os detalhes de implementação. Testes amigáveis à refatoração.
Casos baseados em tabela para limites de borda. Vazio, máximo, unicode, caminhos de erro.
Testes de propriedade para parsers e serializadores. Invariantes de ida e volta.
Pontos de abstração de trait para I/O externo. mockall ou fakes manuais (Mocking & Test Doubles).
Nomeie testes cenario_resultado_esperado. Nomes de filtro cargo test legíveis.

D - Desempenho e CI

Execute cargo nextest run --workspace na CI. Mais rápido que test simples em repositórios grandes.
Separe o job rápido de PR do E2E lento. Mantenha o feedback em minutos.
Faça benchmark de caminhos críticos com Criterion em release. Não em todo PR (Benchmarking with Criterion).
llvm-cov em crates de domínio com limite de ratcheting. A cobertura informa, não substitui a revisão.
Falhe a CI em clippy -D warnings antes de mesclar. Testes passam no mesmo perfil dos desenvolvedores.

E - Assíncrono e HTTP

#[tokio::test] com o sabor correto. current_thread apenas quando !Send for necessário.
Testes Axum via ServiceExt::oneshot. Sem portas aleatórias na camada de unidade.
#[sqlx::test] ou transações revertidas para DB. Sem linhas remanescentes entre testes.
Wrappers de timeout em chamadas externas em testes de integração. Falhe testes travados rapidamente.
Documente variáveis de ambiente para integração opcional (DATABASE_URL). README para E2E local.

FAQs

Testes mínimos para um novo endpoint?

Um caminho feliz de integração, uma falha de autenticação/validação, testes unitários na lógica de domínio extraída.

Quantos testes de propriedade?

Algumas invariantes fortes por parser/serializador; nem toda função precisa de proptest.

Ignorar testes instáveis?

Corrija ou isole com proprietário e prazo; nunca ignore indefinidamente no main.

Testar funções privadas?

Sim, através de testes unitários no mesmo módulo; prefira testar via API pública quando o comportamento for um contrato estável.

Mock ou testcontainers?

Mock/fake para velocidade; testcontainers para peculiaridades de dialeto SQL no job noturno.

Doctests na CI?

cargo test --doc --workspace no PR se a documentação faz parte do contrato da API.

Como testar CLI?

assert_cmd ou snapshot de --help; integração com diretórios temporários para saída de arquivo.

Quando excluir testes?

Quando o comportamento for removido; não mantenha testes para recursos excluídos "por via das dúvidas".

Cobertura de teste em código de "cola"?

Barreira mais baixa aceitável para "wiring" fino; barreira alta em módulos de domínio e segurança.

Quem é o dono da dívida de testes?

Rotação da equipe; vincule correções de testes instáveis à mesma sprint do trabalho de recursos que toca essa área.

Relacionados

Noções Básicas de Testes - para começar
Testes Unitários vs. Integração - posicionamento
Cobertura & CI - pipelines llvm-cov
Linting na CI - portões de qualidade

Versões de Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.

Boas Práticas de Testes

Testes rápidos, determinísticos e significativos dão às equipes Rust confiança para refatorar sem falhas na CI ou duplicação de incidentes de produção.

Como Usar Esta Lista

Aplique ao adicionar um crate ou revisar lacunas de teste após um incidente.
Use como checklist de PR para novos recursos (unitário + integração + documentação onde for público).
Combine com Cobertura e CI para aplicação no pipeline.

A - Estrutura

Coloque testes unitários em #[cfg(test)] mod tests. API privada testada ao lado da implementação.
Testes de integração em tests/ por área de comportamento. Um arquivo por recurso, não um mega-arquivo.
Extraia a biblioteca do binário para testabilidade. main enxuto, lib robusto.
Compartilhe fixtures em tests/common/. Sem copiar e colar configuração de HTTP/DB.
Doctests em exemplos de API pública. Mantenha o rustdoc honesto (Doctests).

B - Determinismo

Sem rede real ou banco de dados de produção no cargo test padrão. Mocks, fakes ou testcontainers atrás de #[ignore].
Use tokio::time::pause em vez de sleep em testes assíncronos. Tempo mais rápido e determinístico.
Isole estado global ou use serial_test. Testes paralelos não devem compartilhar mut statics.
Redija timestamps/UUIDs em snapshots. Arquivos de ouro estáveis (Snapshot Testing).
Semeie testes de propriedade; comite proptest-regressions. Falhas reproduzíveis.

C - Qualidade

Afirme o comportamento, não os detalhes de implementação. Testes amigáveis à refatoração.
Casos baseados em tabela para limites de borda. Vazio, máximo, unicode, caminhos de erro.
Testes de propriedade para parsers e serializadores. Invariantes de ida e volta.
Pontos de abstração de trait para I/O externo. mockall ou fakes manuais (Mocking & Test Doubles).
Nomeie testes cenario_resultado_esperado. Nomes de filtro cargo test legíveis.

D - Desempenho e CI

Execute cargo nextest run --workspace na CI. Mais rápido que test simples em repositórios grandes.
Separe o job rápido de PR do E2E lento. Mantenha o feedback em minutos.
Faça benchmark de caminhos críticos com Criterion em release. Não em todo PR (Benchmarking with Criterion).
llvm-cov em crates de domínio com limite de ratcheting. A cobertura informa, não substitui a revisão.
Falhe a CI em clippy -D warnings antes de mesclar. Testes passam no mesmo perfil dos desenvolvedores.

E - Assíncrono e HTTP

#[tokio::test] com o sabor correto. current_thread apenas quando !Send for necessário.
Testes Axum via ServiceExt::oneshot. Sem portas aleatórias na camada de unidade.
#[sqlx::test] ou transações revertidas para DB. Sem linhas remanescentes entre testes.
Wrappers de timeout em chamadas externas em testes de integração. Falhe testes travados rapidamente.
Documente variáveis de ambiente para integração opcional (DATABASE_URL). README para E2E local.

FAQs

Testes mínimos para um novo endpoint?

Um caminho feliz de integração, uma falha de autenticação/validação, testes unitários na lógica de domínio extraída.

Quantos testes de propriedade?

Algumas invariantes fortes por parser/serializador; nem toda função precisa de proptest.

Ignorar testes instáveis?

Corrija ou isole com proprietário e prazo; nunca ignore indefinidamente no main.

Testar funções privadas?

Sim, através de testes unitários no mesmo módulo; prefira testar via API pública quando o comportamento for um contrato estável.

Mock ou testcontainers?

Mock/fake para velocidade; testcontainers para peculiaridades de dialeto SQL no job noturno.

Doctests na CI?

cargo test --doc --workspace no PR se a documentação faz parte do contrato da API.

Como testar CLI?

assert_cmd ou snapshot de --help; integração com diretórios temporários para saída de arquivo.

Quando excluir testes?

Quando o comportamento for removido; não mantenha testes para recursos excluídos "por via das dúvidas".

Cobertura de teste em código de "cola"?

Barreira mais baixa aceitável para "wiring" fino; barreira alta em módulos de domínio e segurança.

Quem é o dono da dívida de testes?

Rotação da equipe; vincule correções de testes instáveis à mesma sprint do trabalho de recursos que toca essa área.

Relacionados

Noções Básicas de Testes - para começar
Testes Unitários vs. Integração - posicionamento
Cobertura & CI - pipelines llvm-cov
Linting na CI - portões de qualidade

Versões de Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.

Boas Práticas de Testes

Buscar na documentação

Boas Práticas de Testes