Como fazer testes de unidade para garantir que o procedimento armazenado esteja excluindo linhas do banco de dados?

Eu sou novo no teste de unidade e preciso de ajuda com o seguinte.

Eu criei um pequeno projeto para me ajudar a aprender como fazer testes de unidade. A funcionalidade de um dos formulários no meu aplicativo exclui um usuário da tabela Usuário (e outras linhas nas tabelas de mapeamento).

Atualmente, o teste de unidade que criei para testar isso configura os objetos necessários e, em seguida, chama o método de regras de negócios (passando o ID do usuário) que chama o método de acesso a dados para executar o procedimento armazenado que exclui as linhas nas tabelas.

Esse é o método correto para testar se algo está sendo excluído com sucesso? O método de teste / configuração da unidade deve inserir primeiro alguns dados de teste que o teste de unidade exclui?

c# unit-testing

— Theomax
fonte

Respostas:

IMHO, se você está apenas começando a aprender testes de unidade, é melhor deixar os bancos de dados fora de cena por enquanto. Os dados em um banco de dados são mais difíceis de testar - na verdade, quando você está testando código que faz chamadas diretas para um banco de dados, não é mais um teste de unidade, mas um teste de integração .

Você pode codificar o teste de unidade manipulando um banco de dados, mas isso requer mais esforço e ferramentas, incluindo estruturas extras - como DBUnit no mundo Java -, interfaces, simulações etc., que são tópicos mais avançados.

— Péter Török
fonte

Obrigado, minha pergunta provavelmente parece muito nova. Acho que uma das coisas que estou achando difícil é decidir até o que testar! Daí por que pensei testar dados no banco de dados não foi muito diferente de escrever testes que os valores do assert retornados por métodos etc

— Theomax

E escrever testes de unidade para o pequeno projeto que criei me fez perceber que muito do código precisa ser movido para a camada de regras de negócios, em vez de estar no código de formulários por trás! Este deve ser um exemplo de um dos benefícios do teste inapto?

— Theomax

@aspdotnetuser: Certo! Código testável é código de manutenção.

— Kevin cline

when you are directly testing a DB, it isn't a unit test anymore but integration test.Você tem certeza? Se você está testando como um aplicativo funciona com um banco de dados, isso é integração, com certeza, mas é possível testar um banco de dados: blogs.msdn.com/b/atverma/archive/2010/07/28/…

— StuperUser

@StuperUser, meu fraseado não era claro, obrigado pelo feedback :-) O que eu quis dizer foi testar, por exemplo, código C # que depende diretamente (e faz chamadas para) de um banco de dados. Teste de unidade, por exemplo, procedimentos armazenados em um banco de dados, é realmente um tópico diferente. Atualizei minha resposta acima para esclarecer.

— Péter Török

Será muito mais fácil escrever testes de unidade para procedimentos armazenados em SQL. Dê uma olhada no tSQLt . Evite testar novamente os procedimentos armazenados em seus testes de unidade C #; siga o conselho de catraca e zombe do banco de dados para testar o código C #.

— Kevin Cline
fonte

você deve zombar do banco de dados (abstrato) ao testar o formulário

essencialmente fornecendo uma implementação fictícia que faz o mínimo necessário para concluir os testes

Dessa forma, quando você chama enviar no formulário, pode ver se deleteUser no acesso a dados é chamado

— catraca arrepiante
fonte