Gravar teste de unidade para aplicação de banco de dados pesado? [duplicado]

5

Atualmente, estou desenvolvendo um aplicativo da Web baseado em Spring, no qual quase todas as operações criam / atualizam / excluem algo no banco de dados. A lógica principalmente sobre a verificação de condição, de modo que devemos criar / atualizar registros no banco de dados ou não.

O motivo pelo qual eu quero tentar o teste de unidade é que frequentemente encontramos erros de regressão quando a solicitação é alterada ou refatorada. A maioria dos erros vem de alterações no banco de dados, quando não refletem totalmente essas alterações no código. Eu tenho alguma experiência em desenvolvimento web agora, mas parece que não é suficiente para pará-los aparecer.

Meu controlador / serviço não é muito complexo. Acabei de receber o objeto de ligação enviado pelo HttpRequest, verifique a condição & registro em DB. Às vezes, o sistema deve ler o banco de dados, tirar alguns registros & manipulá-los, em seguida, atualizar alguns outros registros. Muito do esforço de codificação encontra-se na interface (HTML / CSS / Javascript) também.

Estou investigando o teste de unidade, e ouvi dizer que quando se trata de operação de banco de dados, não é mais um teste de unidade, já que o teste será lento. Isso é verdade? Então, se meu projeto é strongmente baseado em operações de banco de dados, eu não deveria usar o teste de unidade?

Eu também ouvi falar sobre o DBUnit & algum banco de dados na memória que pode acelerar o teste. Devo usá-los? E como eu posso escrever um bom teste de unidade para operação de banco de dados?

    
por Hoàng Long 12.01.2012 / 04:13
fonte

2 respostas

5

Você provavelmente deve ter testes de unidade e testes integração . Nos testes de unidade, você testa, por exemplo, seus controladores / serviços isoladamente. Para conseguir isso, você pode usar, por exemplo, uma estrutura de simulação como Easymock ou Mockito para reduzir a dependência do banco de dados.

Seus testes de integração devem seguir todo o caminho, desde os controladores / serviços até o banco de dados. Você pode escrever seus testes de integração com a mesma estrutura básica que seus testes de integração (JUnit ou TestNG para nomear os mais populares). Eu pessoalmente gosto do DBUnit para pré-preencher um banco de dados e verificar o estado do banco de dados após o teste. Se você usa um IMO de banco de dados na memória, isso depende muito da sua camada de persistência. Se você usar, por exemplo, uma estrutura JPA que gera suas próprias consultas, eu gosto de ter um banco de dados na memória. Se você escrever suas próprias consultas SQL, pode ser mais difícil usar outro banco de dados do que sua meta de produção, pois você não pode ter certeza de que a sintaxe será equivalente, portanto, um teste de integração com, por exemplo, um banco de dados H2 na memória não significa necessariamente que a Sintaxe funcione com o DB2. Isso se torna ainda mais problemático se você usar procedimentos armazenados.

Um bom teste de integração é executado isoladamente, o que significa que você deve configurar o banco de dados antes de cada teste para evitar a dependência entre os testes. Você não quer que o sucesso de seus testes dependa da ordem em que são executados. Depois de executar suas operações, você deve usar algum tipo de asserção para testar se o estado do banco de dados está de acordo com suas expectativas. O DBUnit, por exemplo, possui suas próprias afirmações para comparar conjuntos de dados ou tabelas.

    
por 12.01.2012 / 07:17
fonte
1

I also heard about DBUnit & some in-memory database which can quicken the test. Should I use them?

Sim.

And how I can write good unit test for database operation?

Da mesma forma que você escreve qualquer outro teste de unidade.

Você olha para a interface definida para sua classe (ou método) e escreve um teste que demonstra que ele funciona quando deveria funcionar e quebra quando deveria quebrar.

Sua configuração pode ser um pouco complexa porque você precisa colocar linhas no banco de dados que correspondam aos requisitos do seu teste de unidade.

    
por 12.01.2012 / 12:04
fonte