Melhor maneira de redefinir o banco de dados para o estado conhecido entre os testes de integração FlexUnit4?

Question

Fundo:

Eu tenho um aplicativo da Web Flex que se comunica com um back-end Java via Blazeds. O cliente Flex é composto por um módulo Flex-Client, que contém os modelos de visualizações e apresentação e um módulo de serviço flexível separado que mantém os modelos (objetos de valores) e objetos de serviço.

Estou no processo de escrever testes de integração assíncronos para os RemoteObjects do módulo de serviço flexível usando o FlexUnit4. Em alguns dos testes, modifico os dados do teste e consulte -os de volta para ver se tudo funciona (uma técnica mostrada aqui: http://saturnboy.com/2010/02/async-testing-with-flexunit4)

Pergunta:

Como faço para redefinir o banco de dados para um estado conhecido antes de cada método de teste FlexUnit4 (ou cadeia do método de teste)? Nos meus testes de integração do Java Server, fiz isso através de uma combinação de transações de DBunit e Spring Test - qual reversão após cada método de teste. Mas essas integração flexunit abrangem várias solicitações e, portanto, várias transações.

Além de implementar uma API de serviço de teste de integração no back -end, como isso pode ser realizado. Certamente outros também se depararam com isso? Perguntas semelhantes foram feitas antes ( Banco de dados de reversão após testes de integração (selênio) ), mas sem respostas satisfatórias.

Answer 1

Existem várias opções:

1. Se você usa sequências para chaves primárias: depois que o banco de dados for carregado com os dados do teste, exclua o gerador de sequência e substitua -o por um que começa com -1 e conta para baixo. Após o teste, você pode excluir objetos com uma chave primária <0. quebras para testes que modificam os dados existentes.

   Uma abordagem semelhante é criar um usuário especial ou, se você tem created Colunas de data e hora, os dados iniciais devem ser antes de alguma data no passado. Isso precisa de índices adicionais, no entanto.

2. Use um banco de dados no servidor que possa ser limpo rapidamente (H2, por exemplo). Adicione uma API de serviço que você pode ligar do cliente para redefinir o banco de dados.

3. Adicione desfazer ao seu aplicativo da web. Isso é um grande esforço, mas uma característica muito legal.

4. Use um banco de dados que permita voltar no tempo com um único comando, como notas de lótus.

5. Não use um banco de dados. Em vez disso, escreva um servidor proxy que responderá à entrada correta com a saída correta. Adicione algum código ao seu servidor real para gravar os dados trocados em um arquivo e crie seus testes a partir disso.

   Ou gravar casos de teste que são executados contra o servidor real e que criam esses arquivos. Isso permitirá que você rastreie quais arquivos alteram quando você modificar o código no servidor ou cliente.

   No servidor, grave testes que garantem que ele faça as modificações corretas do banco de dados.

6. Semelhante a "nenhum banco de dados em todo", oculte todo o código que acessa o banco de dados em uma camada db e use interfaces para acessá -lo. Isso permite que você escreva uma camada de maquete que se comporta como o banco de dados real, mas que salva os dados na memória. Parece simples, mas geralmente é muito trabalho.

Answer 2

Dependendo do tamanho do seu banco de dados de teste, você pode automatizar backups/restaurações limpas que oferecem o ambiente exato que você teve em cada execução de teste.

Eu tenho essa abordagem nos meus projetos atuais (plataforma diferente) e também testamos os scripts de alteração do esquema de dados com a mesma abordagem.

Answer 3

Estou desidratado (minha desculpa favorita para comidas). Sinto muito se esta resposta está muito próxima da resposta "API de serviço de teste de integração no back -end" que você não queria.

A equipe que configurou a Flexunit 'anos atrás' fez escolhas e criou soluções com base em nossa arquitetura, algumas das quais se aplicariam apenas à nossa infraestrutura. Coisas a considerar: 1) Todos os nossos métodos de back-end retornam a mesma classe com mapeamento remotamente. 2) A maioria dos nossos métodos tem um método abstrato que dizer ao método para (ou não) executar uma "transação de início" no início do método e uma "transação de compromisso" no final (não tenho certeza do seu pedaço de banco de dados) .

Este último não é provavelmente a solução mais orientada a objetos, mas aqui está o que uma chamada de teste unitária assíncrona: todo teste de unidade chama de Method-Wrapper, e passamos pelo método-name/pacote local, além de [ ...] Args. Uma BeginTransaction é feita. O método é chamado, passando um falso para o método para testes de unidade de FE (para ignorar as linhas de BeginTransaction e Commitransaction), tudo é executado e a principal classe de 'resposta' é gerada e devolvida ao método de teste de unidade. Um db-rollback é executado e a resposta é retornada ao teste de unidade.

Todos os nossos testes de unidade são baseados em transações rolantes. Eu não sabia falar sobre os problemas que eles tiveram ao configurar esse jive, mas esse é o meu entendimento geral de como Schtuff funciona.

Espero que ajude. Compreensível se não. Boa sorte, --Jeremy