Os testes de unidade contra os testes de integração com Primavera

StackOverflow https://stackoverflow.com/questions/281758

Pergunta

Eu estou trabalhando em um projeto Spring MVC, e eu tenho testes de unidade para todos os vários componentes na árvore fonte.

Por exemplo, se tiver um HomeController controlador, o qual tem de ter um LoginService injectado em que, em seguida, na minha HomeControllerTest teste unidade I simplesmente uma instância do objecto como normal (do lado de fora da mola) e injectar a propriedade: 

protected void setUp() throws Exception {
    super.setUp();
    //...
    controller = new HomeController();
    controller.setLoginService( new SimpleLoginService() );
    //...
}

Isso funciona muito bem para testar cada componente como uma unidade isolada - exceto agora que eu tenho algumas dezenas de classes no projeto, depois de escrever uma classe e escrever um teste de unidade bem sucedida para isso, eu continuo esquecendo de atualizar meu contexto Spring MVC arquivo que faz a fiação-up real no aplicativo implantado. Eu descobrir que eu esqueci de atualizar o arquivo de contexto quando eu implantar o projeto para Tomcat e encontrar um monte de NullPointers de feijão não armado-up.

Então, aqui estão as minhas perguntas:

  1. Este é meu primeiro projeto Spring - é normal para criar testes de unidade para os grãos individuais, como eu fiz, e, em seguida, criar um segundo conjunto de testes (testes de integração) para testar se tudo funciona como esperado com o contexto de aplicação real? Existe uma melhor prática estabelecida para isso?

  2. Além disso, como você separar os testes de unidade a partir dos testes de integração? Eu tenho todo o código-fonte em src, os testes de unidade em test? - deve haver uma pasta de teste 2 (tais como test-integration) para casos de teste de integração

Uma vez que este é o meu primeiro projeto Spring, estou curioso como outros geralmente vai fazer sobre esse tipo de coisa -. E, em vez de re-inventar a roda Eu prefiro pedir ao resto da comunidade

Foi útil?

Solução

Eu não posso falar de ser uma boa prática, mas aqui está o que eu fiz no passado.

Ensaios das unidades:

  • Criar testes de unidade para grãos não-triviais (ou seja, a maioria de sua Primavera feijão relacionados)
  • Use Mocks para serviços injetados sempre que possível (ou seja, a maioria, se não o tempo todo).
  • Use uma convenção de nomenclatura padrão para esses testes no diretório test projeto. Usando Test ou TestCase como um prefixo ou sufixo para o nome da classe parece ser amplamente praticada.

testes de integração:

  • Criar um AbstractIntegrationTestCase que configura uma Spring WebApplicationContext para uso em clases de teste intetgration.
  • Use uma convenção de nomenclatura para testes de integração no diretório test. Eu usei IntTest ou IntegrationTest como um prefixo ou sufixo para estes testes.

Configurar três alvos test Ant:

  1. test-tudo (ou o que você quer nomeá-lo): Executar unitários e de integração testes
  2. teste: Executar testes unitários (só porque test parece ser o uso mais comum para testes de unidade
  3. test-integração:. Executar os testes de integração

Como se observa, você pode usar as convenções de nomenclatura que fazem sentido para o seu projeto.

Como a separação da unidade de testes de integração em um diretório separado, eu não acho que isso importa, desde que os desenvolvedores e suas ferramentas pode encontrar e executá-los facilmente.

Como exemplo, o último Java projeto em que trabalhei com a Primavera usado exatamente o que está descrito acima, com testes de integração e testes de unidade que vivem no mesmo diretório test. projetos Grails, por outro lado, os diretórios de unidades de teste e integração explicitamente separados sob um diretório de teste em geral.

Outras dicas

Alguns pontos isolados:

Sim, é uma abordagem comum para testes Spring - testes de unidade separada e testes de integração, onde o primeiro não carregam qualquer contexto da Primavera.

Para os testes de unidade, talvez considerar zombando para garantir que seus testes são focado em um módulo isolado.

Se você está testes são fiação em uma tonelada de dependências, em seguida, eles não são realmente testes de unidade. Eles são testes de integração onde você está fiação de dependências usando nova, em vez de injeção de dependência. Um desperdício de tempo e esforço duplicado quando seu aplicativo de produção utiliza Primavera!

testes de integração que levem até seus contextos Primavera são úteis.

A anotação @required pode ajudá-lo a garantir que você pegar dependências necessárias em sua fiação da Primavera.

Talvez olhar para Maven que lhe dará fases explícitas para se ligam os testes de unidade e integração sobre a. Maven é bastante utilizada na comunidade Primavera.

Uma grande parte do tedioso double-book-keeping com mola vai embora se você também mudar para um regime puramente anotada, onde você anotar todos os seus feijão com @Component, @Controller, @Service e @Repository. Basta adicionar @Autowired aos atributos que você precisa para se injetado.

Veja a seção 3.11 do manual de referência primavera. http: //static.springframework. org / primavera / docs / 2.5.x / reference / beans.html # feijão-anotação-config

Em uma nota relacionada, temos vindo a utilizar os divisão testes Unit / Integratrion que Keng descrever. Na minha mais recente regime também introduziram uma terceira "classe" de testes "ComponentTests". Estes funcionam com fiação completa primavera, mas com implementações stub com fio (usando filtros e anotações de componentes-scan na primavera).

A razão que fizemos isso foi porque para alguns de o "serviço" camada que você acabar com uma quantidade horrenda de lógica fiação mão-codificado para conectar manualmente o feijão, e as quantidades, por vezes ridículas de mock-objetos. 100 linhas de fiação de 5 linhas de teste não é incomum. Os testes de componentes aliviar este problema.

Use a interface InitializingBean (implementa um método "afterPropertiesSet") ou especificar um-método init para seus feijões. InitializingBean geralmente é mais fácil porque você não precisa se lembrar de adicionar o método init para seus feijões.

Use afterPropertiesSet para garantir que tudo é injetado como não nulo, se ele é nulo, lançar uma exceção.

Quando eu criei testes de integração para aplicações web, eu colocá-los em um diretório separado. Eles são construídos usando JUnit ou TestNG e interagir com o sistema em teste usando algo como selênio que atinge as páginas da web como se fossem usuários. O ciclo seria assim: compilação, executar testes de unidade, construir o aplicativo web, implantá-lo em um servidor em execução, executar os testes, undeploy o aplicativo, e resultados do relatório. A idéia é testar todo o sistema.

No que diz respeito à execução de testes de unidade separadamente dos testes de integração, eu coloquei todos estes elementos em um diretório de integração-teste e executá-los usando IDE / Ant usando uma abordagem como este . Funciona para mim.

a diferença entre teste de unidade e teste de integração é, teste de unidade não necessariamente carregar seu contexto, você está focando o código que você escreveu - ele funciona falhar rápido, isto é, com e sem exceções, zombando qualquer depende chamadas iniciar. Mas no caso de testes de integração, você carrega contexto e executar fim ao teste final como cenários reais.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top