No trabalho, começamos um aplicativo altamente baseado em Javascript (na verdade, usando Coffeescript, mas ainda assim), do qual tenho implementado um sistema de teste automatizado usando JsTestDriver e fabric.
Nunca escrevemos algo com tanto Javascript, então até agora nunca fizemos nenhum teste de Javascript. Não tenho certeza do que exatamente deveríamos testar em nossos testes de unidade. Nós escrevemos plugins JQuery para várias coisas, por isso é óbvio que eles devem ser verificados quanto à correção quanto possível com o JsTestDriver, mas todos os outros membros da minha equipe parecem pensar que deveríamos testar também o Javascript no nível da página.
Acho que não deveríamos testar o Javascript no nível da página como testes de unidade, mas usar um sistema como o Selenium para verificar se tudo funciona como esperado. Meu principal raciocínio é que, no momento, é garantido que os testes Javascript no nível da página falhem no JsTestDriver, porque eles estão tentando acessar elementos no DOM que não podem existir.
Então, o que deve ser testado em unidade em Javascript?
fonte
Respostas:
Teste tudo o que puder.
A lógica pura pode ser testada facilmente.
Se o seu código interage com o DOM ou a rede, é muito mais difícil.
Se você pode abstrair um pedaço de código para trabalhar em um elemento DOM arbitrário em vez de um elemento específico, poderá testá-lo mais facilmente. (Faça o elemento trabalhar em um parâmetro).
O código que usa o Ajax pode ser testado simplesmente chamando a função de retorno de chamada com dados fixos. Eu tive alguns testes em que substituí
$.ajaxa minha própria função. Apenas certifique-se de colocar de volta o verdadeiro quando terminar!O que você encontrará é que "javascript no nível da página" realmente significa "código fortemente acoplado" e, se você dissociar as partes do código, poderá testá-las independentemente.
(O Selenium não é uma ferramenta de teste de unidade. É ótimo para cenários de alto nível, mas você não pode testar com ele e não funciona em um ambiente isolado.)
fonte
$(document).ready(...)....é. :-) Eu sinto que você deve conseguir isso em uma única função nomeada que também é testada. Em seguida, seu código não testado é uma única linha. (Agora que é uma meta, não uma determinada Na prática Eu sempre tive mais de uma linha de código não foi testado..)Algoritmos de teste. As partes relacionadas à GUI são mais dependentes de um navegador específico, portanto precisam ser testadas usando utilitários do tipo selênio.
Seu código, é claro, deve conter algoritmos como um pedaço isolado de código, se não existir, o teste de unidade é quase impossível.
plugins jquery, btw, não são fáceis de testar por unidade.
fonte
Eu costumava trabalhar com Java e, pelo que vejo, o teste de unidade Java é mais fácil do que o teste de unidade JavaScript, porque o Java é mais rígido.
Eu sou vendido nesse desenvolvimento orientado a teste é a melhor coisa, então também estou explorando como fazer o teste unitário de JavaScript. Em Java, zombei do código que fez a conexão com o banco de dados, os Data Access Objects, e comparo-o ao código em JavaScript que altera o DOM e o código que faz chamadas AJAX ao servidor.
O que estou dizendo é que me parece que o que deve ser testado é a lógica explicitamente. Por exemplo, você não deseja fazer uma chamada AJAX ao executar testes de unidade porque (a) você precisa que o servidor esteja em execução eb (b) é lento e uma das diretrizes do teste de unidade é que ele precisa ser super rápido para que os desenvolvedores não evitem executá-los como a cada minuto.
Outra orientação é que o processo de integração contínua envie um e-mail dizendo que encontrou um teste de unidade que falhou.
fonte