Trabalho com muitos aplicativos da Web que são direcionados por bancos de dados de complexidade variada no back-end. Normalmente, há uma camada ORM separada da lógica de negócios e de apresentação. Isso torna o teste de unidade da lógica de negócios bastante simples; as coisas podem ser implementadas em módulos discretos e todos os dados necessários para o teste podem ser falsificados por meio de zombaria de objetos.
Mas testar o ORM e o próprio banco de dados sempre foi repleto de problemas e compromissos.
Ao longo dos anos, tentei algumas estratégias, nenhuma das quais me satisfez completamente.
Carregue um banco de dados de teste com dados conhecidos. Execute testes no ORM e confirme se os dados corretos retornam. A desvantagem aqui é que o banco de dados de teste precisa acompanhar as alterações de esquema no banco de dados do aplicativo e pode ficar fora de sincronia. Ele também depende de dados artificiais e não pode expor bugs que ocorrem devido a entradas estúpidas do usuário. Finalmente, se o banco de dados de teste for pequeno, não revelará ineficiências como um índice ausente. (OK, esse último não é realmente para o que o teste de unidade deve ser usado, mas não dói.)
Carregue uma cópia do banco de dados de produção e teste contra isso. O problema aqui é que você pode não ter idéia do que está no banco de dados de produção a qualquer momento; seus testes podem precisar ser reescritos se os dados mudarem com o tempo.
Algumas pessoas apontaram que essas duas estratégias dependem de dados específicos, e um teste de unidade deve testar apenas a funcionalidade. Para esse fim, vi sugestões:
- Use um servidor de banco de dados simulado e verifique apenas se o ORM está enviando as consultas corretas em resposta a uma determinada chamada de método.
Quais estratégias você usou para testar aplicativos orientados a banco de dados, se houver? O que funcionou melhor para você?