Como posso unidade testar uma interface gráfica?

https://stackoverflow.com/questions/215458

03-07-2019
|

Pergunta

Os cálculos no meu código está bem testado, mas porque há muito código GUI, a minha cobertura de código geral é menor do que eu gostaria. Existem quaisquer orientações sobre o código GUI-testes de unidade? Será que ainda faz sentido?

Por exemplo, existem gráficos em meu aplicativo. Eu não tenho sido capaz de descobrir como automatizar os testes dos gráficos. É preciso um olho humano, AFAIK, para verificar se o gráfico está correta.

(estou usando Java Swing)

Solução

projetos como MVP e MVC normalmente tentam abstrato como muita lógica fora do GUI real possível. Um artigo muito popular sobre isso é "A caixa de diálogo Humble" por Michael Feathers. Pessoalmente, eu tive experiências mistas com a tentativa de mover a lógica fora da UI - por vezes, tem funcionado muito bem, e em outros momentos ele tem sido mais problemas do que vale a pena. É um pouco fora da minha área de especialização embora.

Outras dicas

É claro que a resposta é usar MVC e mover tanto lógica fora do GUI possível.

Dito isto, ouvi de um colega de trabalho há muito tempo que quando SGI era portar OpenGL para um novo hardware, eles tinham um monte de testes de unidade que gostaria de chamar um conjunto de primatives para a tela, em seguida, calcular uma soma MD5 do Suavizador de quadros. Este valor pode então ser comparado com bons valores de hash conhecidos para determinar rapidamente se o API é por pixel preciso.

Você pode tentar UISpec4J é uma biblioteca de testes funcionais e / ou unidade de Open Source para aplicações Java baseadas em Swing ...

Aqui estão algumas dicas:

Tente remover a maior parte do código é possível a partir da GUI (tem controlador e modelo de objeto) Desta forma, você será capaz de testá-los sem a GUI.

Para o gráfico, você deve testar o valor que você fornece para o código que gerar o gráfico.

Você pode tentar usar Pepino e Swinger para escrever testes de aceitação funcionais na planície Inglês para aplicações GUI swing. Swinger utiliza a biblioteca de Jemmy Netbeans' sob o capô para conduzir o aplicativo.

Pepino permite testes de escrita assim:

 Scenario: Dialog manipulation
    Given the frame "SwingSet" is visible
    When I click the menu "File/About"
    Then I should see the dialog "About Swing!"
    When I click the button "OK"
    Then I should not see the dialog "About Swing!"

Dê uma olhada neste Swinger vídeo de demonstração para vê-lo em ação.

Há Selenium RC , que irá automatizar testar uma web baseada UI. Ela irá gravar ações e reproduzi-las. Você ainda precisará percorrer as interações com sua interface do usuário, de modo que este não vai ajudar com a cobertura, mas pode ser usado para compilações automatizadas.

O teste é uma forma de arte. Concordo a lógica deve ser removido GUI, tanto quanto possível. Podemos, então, concentrar a nossa unidade de teste lá. Como os testes que qualquer outra coisa é sobre a redução de riscos. Você sempre não precisa de teste de tudo, mas um monte de vezes a melhor coisa é quebrar o teste diferente para em diferentes áreas.

A outra questão é o que você está realmente tentando testar na camada de interface do usuário. teste de UI é o teste mais caro, pois geralmente leva mais tempo para criar, manter e é o mais frágil. Se você testar a lógica de saber as coordenadas estão corretas antes de tentar traçar a linha que você está testando especificamente? Se você quiser testar um gráfico com uma linha vermelha é desenhado. você pode dar-lhe um conjunto de coordenadas pré-determinadas e testar se certas pixels são vermelhas ou não vermelho? Como sugerido acima comparações bitmap trabalho, selênio, mas meu foco principal seria não mais teste da GUI, mas sim testar a lógica que vai ajudar a criar a interface do usuário e, em seguida, se concentrar no que parte das quebras de interface do usuário ou é suspeito e focar um punhado de testes lá.

Você pode usar JFCUnit para testar seu GUI, mas os gráficos pode ser mais desafiador. Eu tenho em um par de ocasiões tomadas instantâneos da minha GUI e comparou-o automaticamente para uma versão anterior. Enquanto isso não fornecer um teste real, ele alerta que, se uma compilação automática falha em produzir o resultado esperado.

O que eu reunir a partir de sua pergunta é que você está procurando uma maneira automatizada para testar o seu comportamento GUI em detalhes, o exemplo que você dá é testar se uma curva é desenhado corretamente.

estruturas de teste de unidade fornecem uma maneira de fazer testes automatizados, mas acho que o tipo de testes que você quer fazer são complicados testes de integração que verificam o comportamento correto de uma multidão de aulas, entre as quais as classes do seu GUI kit de ferramentas / biblioteca , que você não deve querer teste.

Suas opções dependem muito do que plataformas / kits de ferramentas / quadros que você usa: por exemplo, um aplicativo usando Qt como framework GUI pode usar Squish para automatizar seus testes. Você verificar os resultados de seus testes uma vez, e testes executados automaticamente subseqüentes comparar resultados com os resultados verificados.

Janela Licker para Swing & Ajax

Pelo que eu sei, isso é bastante complicado, e realmente depende do idioma - várias línguas têm sua própria maneira de testar GUI, mas se você realmente precisa para testar a GUI (em oposição ao modelo de interação / gui), você muitas vezes têm de simular um real botões usuário clicar. Por exemplo, o quadro SWT usado em Eclipse fornece SWTBot , JFCUnit já foi mencionado, a Mozilla tem sua própria maneira de simular isso em XUL (e pelo que eu li em seus blogs, estes testes parecem ser bastante frágil).

Às vezes você tem que tomar um screenshot, e teste para renderização de pixel-perfect (creio que a Mozilla faz isso para verificar se há páginas corretamente prestados) - isso requer uma configuração mais longas, mas pode ser o que você precisa para os gráficos. Dessa forma, quando você atualizar seu código e uma quebra de teste, você tem que verificar manualmente a imagem se a falha era real, ou você melhorou o gráfico de renderização de código para gerar gráficos mais bonitos e necessidade de atualizar as imagens.

Se você estiver usando Swing, FEST-Swing é útil para dirigir seu GUI e testando as afirmações. Isso torna bastante simples para testar as coisas como "se eu clicar o botão A, de diálogo B deve ser exibida" ou "se eu selecionar a opção 2 no menu drop-down, todas as caixas de seleção deve tornar-se desmarcada ".

O cenário gráfico que você menciona não é tão fácil de teste. É muito fácil de obter cobertura de código para componentes GUI apenas criando e mostrando-lhes (e talvez dirigir-los com FEST). No entanto, fazer afirmações significativas é a parte mais difícil (e cobertura de código, sem afirmações significativas é um exercício de auto-engano). Como você testar se o gráfico não foi desenhado de cabeça para baixo, ou muito pequena?

Eu acho que você só tem que aceitar que alguns aspectos de GUIs não pode ser testada de forma eficaz pelos testes de unidade automatizados e que você terá que testá-los de outras maneiras.

Não é o seu trabalho para testar a biblioteca GUI. Assim, você pode evitar a responsabilidade de verificar o que realmente está desenhado em propriedades tela e verifique Widgets vez, confiando a biblioteca que representam com precisão o que é desenhado.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow