Teste das Aplicações Centrais do EF

Os testes são uma preocupação importante para quase todos os tipos de aplicações – permitem-lhe ter a certeza de que a sua aplicação funciona corretamente e deixam imediatamente claro se o seu comportamento regredir no futuro. Como os testes podem afetar a forma como o seu código é arquitetado, é altamente recomendado planear os testes cedo e garantir uma boa cobertura à medida que a sua aplicação evolui. Esta secção introdutória oferece uma visão geral rápida de várias estratégias de teste para aplicações que utilizam o EF Core.

Envolvendo a base de dados (ou não)

Ao escrever testes para a sua aplicação EF Core, uma decisão básica é se os seus testes vão envolver o sistema de base de dados de produção – tal como a sua aplicação – ou se os testes vão correr contra um teste duplo, que substitui o sistema de base de dados de produção. Dois exemplos proeminentes de duplicações de teste no contexto do EF Core são o modo SQLite em memória e o fornecedor em memória.

Para uma comparação e análise aprofundada das diferentes abordagens, consulte Escolher uma estratégia de teste. Abaixo está um breve resumo ponto a ponto para o ajudar a familiarizar-se com as diferentes opções:

• Os programadores frequentemente evitam testar contra o seu sistema de base de dados de produção porque acreditam que isso é difícil ou lento. Isto nem sempre é verdade na nossa experiência, e sugerimos que dê uma oportunidade a esta abordagem: testar contra o seu sistema de base de dados de produção fornece técnicas para o fazer de forma fiável e eficiente. Escrever pelo menos alguns testes contra a tua base de dados é geralmente necessário em qualquer caso – para garantir que a tua aplicação realmente funciona contra a base de dados de produção – e os testes que não envolvem a base de dados podem ser limitados no que permitem testar (ver abaixo).
• O fornecedor em memória não se comportará como a sua base de dados real em muitos aspetos importantes. Algumas funcionalidades não podem ser testadas com ele de todo (por exemplo, transações, SQL bruto, etc.), enquanto outras funcionalidades podem comportar-se de forma diferente da sua base de dados de produção (por exemplo, sensibilidade a maiúsculas minúsculas nas consultas). Embora a in-memory possa funcionar para cenários simples e restritos de consulta, é altamente limitada e desencorajamos a sua utilização.
  • A simulação DbSet para consultas é complexa e difícil de gerir, e sofre das mesmas desvantagens que a abordagem na memória; também desencorajamos esta prática.
• O modo SQLite em memória oferece melhor compatibilidade com bases de dados relacionais de produção, uma vez que o SQLite é ele próprio uma base de dados relacional completa. No entanto, ainda haverá algumas discrepâncias importantes entre o SQLite e a sua base de dados de produção, e algumas funcionalidades não podem ser testadas de todo (por exemplo, métodos específicos do fornecedor no EF.Functions).
• Para uma abordagem de teste que permita usar um duplo de teste fiável para toda a funcionalidade do seu sistema de base de dados de produção, é possível introduzir uma camada de repositório na sua aplicação. Isto permite-lhe excluir completamente o EF Core dos testes e simular completamente o repositório; No entanto, isto altera a arquitetura da sua aplicação de uma forma significativa e envolve mais custos de implementação e manutenção.

Leitura adicional

Para informações mais detalhadas, consulte Escolher uma estratégia de testes. Para diretrizes de implementação e exemplos de código, consulte Testes contra o seu sistema de base de dados de produção e Testes sem o seu sistema de base de dados de produção.