Como persistência eu teste de unidade?

votos
43

Como um novato na prática o desenvolvimento orientado a testes, eu muitas vezes acabam em um dilema quanto à forma de unidade de persistência de teste para um banco de dados.

Eu sei que, tecnicamente, isso seria um teste de integração (não um teste de unidade), mas eu quero descobrir as melhores estratégias para o seguinte:

  1. consultas de teste.
  2. Testando inserções. Como eu sei que a inserção que deu errado se ele falhar? Eu posso testá-lo, inserindo e, em seguida, consultando, mas como posso saber que a consulta não estava errado?
  3. Testando atualizações e exclui - mesmo que inserções de teste

Quais são as melhores práticas para fazer isso?


Em relação SQL testes: Estou ciente de que isso poderia ser feito, mas se eu usar um Mapper O / R como NHibernate, que atribui algumas verrugas nomenclatura nos aliases utilizados para as consultas de saída e, como que é um pouco imprevisível Eu não tenho certeza eu poderia testar para isso.

Devo apenas, abandonar tudo e simplesmente confiar em NHibernate? Eu não tenho certeza que é prudente.

Publicado 05/08/2008 em 10:43
fonte usuário
Em outras línguas...                            


10 respostas

votos
16

Olhe para Unidade DB. É uma biblioteca Java, mas deve haver um C # equivalente. Ele permite que você preparar o banco de dados com um conjunto de dados para que você saiba o que está no banco de dados, então você pode fazer interface com a unidade DB para ver o que está no banco de dados. Ele pode ser executado contra vários sistemas de banco de dados, assim você pode usar sua configuração de banco de dados real, ou usar outra coisa, como HSQL em Java (uma implementação de banco de dados Java com uma opção de memória).

Se você quiser testar que seu código está usando o banco de dados corretamente (que você provavelmente deveria estar fazendo), então este é o caminho a percorrer para isolar cada teste e garantir o banco de dados esperado dados preparados.

Respondeu 11/08/2008 em 10:40
fonte usuário

votos
15

Como disse Mike Stone , DbUnit é ótimo para obter o banco de dados em um estado conhecido antes de executar seus testes. Quando os testes terminarem, DbUnit pode colocar o banco de dados de volta para o estado em que estava antes de executar os testes.

DbUnit (Java)

DbUnit.NET

Respondeu 25/08/2008 em 14:22
fonte usuário

votos
4

Você faz o teste de unidade zombando a conexão banco de dados. Dessa forma, você pode construir cenários onde as consultas específicas no fluxo de uma chamada de método ter sucesso ou falhar. Eu costumo construir minhas expectativas simulados para que o texto consulta real é ignorado, porque eu realmente quero para testar a tolerância a falhas do método e como ele lida com si - as especificidades do SQL são irrelevantes para esse fim.

Obviamente, isso significa que o teste não vai realmente verificar se o método funciona , porque o SQL pode estar errado. Este é o lugar onde os testes de integração chutar. Para isso, espero que alguém vai ter uma resposta mais completa, como eu estou apenas começando a se familiarizar com os eu.

Respondeu 05/08/2008 em 10:47
fonte usuário

votos
3

Eu escrevi um post aqui sobre unidade de testar a camada de dados que cobre este problema exato. Desculpas para a ficha (vergonhoso), mas o artigo é muito longo para postar aqui.

Espero que ajude você - ele tem trabalhado muito bem para mim ao longo dos últimos 6 meses em 3 projetos ativos.

Saudações,

Rob G

Respondeu 13/08/2008 em 00:23
fonte usuário

votos
2

Para projetos baseados JDBC, quadro Acolyte pode ser usado: http://acolyte.eu.org . Ele permite que a maquete de acesso de dados que deseja testes, beneficiando de JDBC abstração, sem ter que gerenciar um banco de dados de teste específico.

Respondeu 09/07/2014 em 10:20
fonte usuário

votos
2

Para NHibernate, eu definitivamente defendem apenas zombando o NHibernate APIpara testes de unidade - confiar a biblioteca para fazer a coisa certa. Se você quiser garantir que os dados realmente vai para o DB, faça um teste de integração.

Respondeu 05/08/2008 em 12:20
fonte usuário

votos
2

O problema que eu experimentei quando o teste de unidade de persistência, especialmente sem um ORM e zombando assim o seu banco de dados (conexão), é que você realmente não sei se as consultas sucesso. Pode ser que você suas consultas são projetados especificamente para uma versão banco de dados específico e só ter sucesso com essa versão. Você nunca vai achar que se você zombar de seu banco de dados. Então, na minha opinião, o teste de unidade de persistência só é de uso limitado. Você deve sempre adicionar testes de corrida contra o banco de dados alvo.

Respondeu 05/08/2008 em 11:29
fonte usuário

votos
1

Eu costumo criar um repositório e usar isso para salvar a minha entidade, em seguida, recuperar um novo. Então eu afirmar que a recuperada é igual à salvo.

Respondeu 27/08/2008 em 22:17
fonte usuário

votos
1

testes de unidade tecnicamente de persistência não são testes de unidade que são testes de integração.

Com C # usando MbUnit, basta usar os atributos SqlRestoreInfo e rollback

    [TestFixture]
    [SqlRestoreInfo(<connectionsting>, <name>,<backupLocation>]
    public class Tests
    {

        [SetUp]
        public void Setup()
        {

        }

        [Test]
        [RollBack]
        public void TEST()
        {
           //test insert. 
        }
    }

O mesmo pode ser feito em NUnit, excpet os nomes de atributos diferem ligeiramente.

Como para verificar se a consulta foi succeful, normalmente você precisa segui-lo com uma segunda consulta para ver se o banco de dados foi alterado conforme o esperado.

Respondeu 05/08/2008 em 12:27
fonte usuário

votos
1

Também gostaria de zombar do banco de dados e verificar que as consultas são o que você esperava. Há o risco de que o teste verifica o sql errado, mas isso seria detectado nos testes de integração

Respondeu 05/08/2008 em 11:19
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more