JUnit para código de banco de dados

Question

Estou tentando implementar testes unitários e atualmente tenho algum código que faz o seguinte:

1. Consulta banco de dados externo, carregando em uma tabela de alimentação
2. Consulta uma visualização, que é um delta das minhas tabelas de feed e dados, atualizando a tabela de dados para combinar com a tabela de feeds

minha estratégia de teste unitário é esta:

Tenho um banco de dados de testes que posso manipular livremente.

1. em setUP(), carregue alguns dados em meu banco de dados de teste
2. execute meu código, usando meu banco de dados de teste como fonte
3. inspecionar a tabela de dados, verificando contagens e a existência/não existência de determinados registros
4. limpar banco de dados de teste, carregando um conjunto diferente de dados
5. execute o código novamente
6. inspecionar a tabela de dados novamente

Obviamente, tenho os conjuntos de dados que carrego no banco de dados de origem configurados de forma que sei que certos registros devem ser adicionados, excluídos, atualizados, etc.

Parece que isso é um pouco complicado e deveria haver uma maneira mais fácil?alguma sugestão?

Answer 1

Sua intenção é testar a visualização que gera os deltas ou testar se seu código adiciona, exclui e atualiza corretamente em resposta à visualização?

Se você quiser testar a visualização, você pode usar uma ferramenta como DBUnit para preencher suas tabelas de feeds e dados com vários dados cujo delta você calculou manualmente.Então, para cada teste você verificaria se a visualização retorna um conjunto correspondente.

Se você quiser testar como seu código responde às diferenças detectadas pela visualização, eu tentaria abstrair o acesso ao banco de dados.Eu imagino um método java para o qual você pode passar um conjunto de resultados (ou lista de POJO/DTO's) e retornar uma lista de matrizes de objetos de parâmetros (novamente, ou POJO's) a serem adicionadas.Outros métodos analisariam a lista de diferenças em busca de itens a serem removidos e atualizados.Você pode então criar um conjunto de resultados simulados ou pojos, passá-los para o seu código e verificar se os parâmetros corretos são retornados.Tudo sem tocar em um banco de dados.

Acho que o segredo é dividir seu processo em partes e testar cada uma delas da forma mais independente possível.

Answer 2

Unidade de banco de dados atenderá às suas necessidades.Uma coisa a observar é que eles passaram a usar SLF4J como fachada de registro em vez de JCL.Você pode configurar o SLF4J para encaminhar o log para JCL, mas esteja avisado se estiver usando Maven DbUnit é uma droga em seu provedor de log Nop por padrão, então você terá que usar uma exclusão, eu blogado sobre este conflito recentemente.

Answer 3

Eu uso DbUnit, mas também trabalho muito para não ter que testar no banco de dados.Os testes que vão contra o banco de dados devem existir apenas com a finalidade de testar a interface do banco de dados.Portanto, tenho conexões simuladas de banco de dados que posso definir os dados para uso em todos os demais testes.

Answer 4

Além do DBUnit já sugerido, você pode querer dar uma olhada em Unidades.Ele usa DBUnit, mas fornece mais que isso (citando no site):

• Manutenção automática de bancos de dados, com suporte para scripts incrementais, repetíveis e pós -processamento
• Desative restrições automaticamente e defina sequências com um valor mínimo
• Suporte para Oracle, Hsqldb, MySql, DB2, Postgresql, MsSql e Derby
• Simplifique a configuração da conexão do banco de dados de teste
• Inserção simples de dados de teste com DBUnit * Executar testes em uma transação
• JPA Entidade Gerente de criação e injeção de hibernato, toplink e * criação e sessão de factory de hibernação
• Teste automaticamente o mapeamento de entidades JPA / objetos mapeados de hibernato com o banco de dados

Answer 5

Se você estiver usando Maven, uma opção é usar o plugin-sql-maven.Ele permite que você execute scripts de inicialização/preenchimento do banco de dados durante o ciclo de construção do maven.