Testando aplicativos EF Core

Testes são fundamentais para quase todos os tipos de aplicativo, pois permitem que você tenha certeza de que seu aplicativo funciona corretamente e avisa imediatamente se o comportamento dele regredir futuramente. Como os testes podem afetar a forma como o código é arquitetado, recomendamos veementemente o planejamento de um teste antecipado e a garantia de uma boa cobertura à medida que o aplicativo evolui. Esta seção introdutória fornece uma visão geral rápida de várias estratégias de teste para aplicativos que usam o EF Core.

Envolvendo o banco de dados (ou não)

Ao escrever testes para seu aplicativo EF Core, uma decisão básica que você precisa tomar é se seus testes envolverão seu sistema de banco de dados de produção – assim como seu aplicativo faz – ou se seus testes serão executados em um duplo teste, que substitui seu sistema de banco de dados de produção. Dois exemplos de destaque dos duplos testes no contexto do EF Core são o modo SQLite na memória e o provedor na memória.

Para obter uma comparação detalhada e uma análise das diferentes abordagens, confira Escolher uma estratégia de teste. Veja abaixo um resumo ponto a ponto curto para ajudar você a se atualizar com as diferentes opções:

• Os desenvolvedores frequentemente evitam testes em seu sistema de banco de dados de produção porque acreditam que isso é difícil ou lento. Segundo nossa experiência, isso nem sempre é verdade, e sugerimos dar uma chance a essa abordagem: Testar em seu sistema de banco de dados de produção fornece técnicas para fazer isso de forma confiável e eficiente. Normalmente, é necessário escrever pelo menos alguns testes em seu banco de dados de qualquer forma – para garantir que seu aplicativo realmente funcione em seu banco de dados de produção – e os testes que não envolvem o banco de dados podem ser limitados no que permitem que você teste (veja abaixo).
• O provedor na memória não se comportará como seu banco de dados real de várias maneiras importantes. Alguns recursos não podem ser testados de forma alguma (por exemplo, transações, SQL bruto...), enquanto outros recursos podem se comportar de forma diferente do banco de dados de produção (por exemplo, maiúsculas e minúsculas em consultas). Embora a opção na memória possa funcionar para cenários de consulta simples e restritos, ela é altamente limitada e desencorajamos seu uso.
  • Simular DbSet para consultas é algo complexo e difícil, e sofre das mesmas desvantagens que a abordagem na memória; e também desencorajamos isso.
• O modo SQLite na memória oferece melhor compatibilidade com bancos de dados relacionais de produção, uma vez que o SQLite é em si um banco de dados relacional completo. No entanto, ainda haverá algumas discrepâncias importantes entre o SQLite e o banco de dados de produção, e alguns recursos não podem ser testados (por exemplo, métodos específicos do provedor no EF.Functions).
• Para uma abordagem de teste que permite o uso de um duplo teste confiável para todas as funcionalidades do sistema de banco de dados de produção, é possível introduzir uma camada de repositório em seu aplicativo. Isso permite que você exclua totalmente o EF Core do teste e simule totalmente o repositório; no entanto, isso altera a arquitetura do aplicativo de uma forma que pode ser significativa, e envolve mais custos de implementação e manutenção.

Leitura adicional

Para saber mais, confira Escolher uma estratégia de testes. Para obter diretrizes de implementação e exemplos de código, confira Testar em seu sistema de banco de dados de produção e Testar sem o sistema de banco de dados de produção.