Testes: banco de dados em memória
O curso parte de uma pergunta: uma suíte de testes Rails deveria rodar contra um banco SQLite em memória? A resposta vem da medição. Uma suíte RSpec de 1.206 exemplos é perfilada, e as idas e voltas ao banco são comparadas com o boot e com os exemplos lentos do sandbox. O curso explica o modo :memory: do SQLite e o cache compartilhado. Depois pesa recursos do PostgreSQL como jsonb, pg_trgm e ILIKE contra o risco de divergência silenciosa. Também trata de testes transacionais, de outras formas de acelerar a suíte e dos projetos onde um banco em memória cabe.
O que você vai aprender
- ✓Como perfilar uma suíte RSpec com --profile antes de otimizar
- ✓Como bancos :memory: do SQLite, URIs com cache compartilhado e pools de conexão se relacionam
- ✓Por que jsonb, pg_trgm, ILIKE e funções de janela fazem testes no SQLite divergirem da produção
- ✓Como fixtures transacionais e savepoints isolam cada exemplo
- ✓Ganhos práticos: rodar um arquivo, --only-failures, ordem aleatória, build em vez de create, parallel_tests
- ✓Quando um banco em memória ou um substituto em memória é a escolha certa
Para onde o tempo realmente vai
Este curso é sobre um truque conhecido. Rodar a suíte de testes contra um banco SQLite em memória em vez de um banco real, e ver ela ficar mais rápida. O truque é real. Se ele ajuda você é uma pergunta com resposta mensurável, e medir primeiro é a disciplina inteira.
Ler a aula completa grátis →Currículo
7 aulasPara onde o tempo realmente vai
Perfila uma suíte de 1.206 exemplos com rspec --profile e mostra que o banco ocupa cerca de 3 dos 70 segundos.
O que é de fato um banco em memória
Explica o modo :memory: do SQLite, por que o pool de conexões exige a URI com cache compartilhado e a carga do esquema.
O que custaria aqui
Mostra como colunas jsonb, pg_trgm, ILIKE e funções de janela fariam testes no SQLite divergirem da produção em silêncio.
Testes transacionais: o mecanismo real
Explica como fixtures transacionais fazem rollback de cada exemplo, como savepoints funcionam e onde conexões separadas os quebram.
As alavancas que de fato funcionam
Ordena as opções que ajudam aqui: rodar um arquivo, --only-failures, ordem aleatória, build em vez de create e parallel_tests.
Quando em memória é a resposta certa
Descreve onde a memória cabe: gems, engines, aplicações de esquema simples com CI no banco real, e substitutos de cache, fila ou e-mail.
Juntando tudo: uma decisão, medida
Revisa passo a passo a decisão tomada pela medição e a regra geral de perfilar antes de escolher uma otimização.