Examinei a lista bastante longa de estruturas de teste em https://github.com/ry/node/wiki/modules#testing . Qual é a experiência com essas estruturas?
Obviamente, a capacidade de rodar no navegador seria um grande bônus, mas estou principalmente interessado no Node.js. Algo com uma inclinação fortemente assíncrona seria ótimo.
Respostas:
Atualizar:
Mocha é o melhor na minha opinião.
Qual é a experiência com essas estruturas?
Eu brinquei com o expresso, que é um framework de teste muito legal, que também tem cobertura de teste. Foi criado por TJ Holowaychuk, que também é o criador do Express.js (incrivelmente rápido (e pequeno) framework de desenvolvimento da Web JavaScript do lado do servidor, construído no Node.js. e no Connect). Vi recentemente que ele também tem uma biblioteca interessante chamada should.js, que pode ser usada junto com o Expresso para uma experiência de teste ainda melhor.
Obviamente, a capacidade de rodar no navegador seria um grande bônus
Não acredito que ele possa ser executado no navegador, mas também não entendo por que você deseja executá-lo dentro do navegador?
mas estou principalmente interessado em Node.js. Algo com uma inclinação fortemente assíncrona seria ótimo.
Citação do expresso:
O argumento passado para cada retorno de chamada é beforeExit, que normalmente é usado para afirmar que os retornos de chamada foram chamados.
Você pode usar beforeExit para testar funções assíncronas.
DICA: Siga TJ Holowaychuk no GitHub , porque ele cria um código-fonte aberto muito bom.
Eu uso o VowsJS, que é fácil de usar a estrutura assíncrona de BDD (Behavior Driven Development) e faço o trabalho.
Pelo que vejo ultimamente, é o que muitos escolhem para testar seus módulos NPM, então acredito que até agora é o melhor para usar.
Algumas estruturas de teste populares que podem ser usadas com o NodeJS também são:
Você também pode ver uma lista de estruturas de teste JavaScript aqui
Poucas bibliotecas que poderiam ajudá-lo a escrever um código melhor são:
Há também o Bamboo CI Server da Atlassian que automatiza compilações e testes. É um pacote para o Apache / Tomcat (que sux porque usa Java e que o torna muito pesado) também não é gratuito, mas possui uma licença inicial que custa US $ 10, por isso acredito que seja acessível. É o mais destacado de todos os servidores de IC que encontrei até agora e suporta todos os testes de unidade que suportam xUnit, o que significa que você pode executar compilações / testes para qualquer idioma com o Bamboo.
Outra opção para o IC com o NodeJS é o Travis, que muitas pessoas usam para seus projetos de código aberto, como diz Um serviço de integração contínua hospedado para a comunidade de código aberto.
Há também uma discussão em grupo do Google com o tópico Integração Contínua para Projetos JS de Nó .
Com base nos comentários do autor da pergunta acima, tentei fazer votos e resolveu muitos problemas que estava tendo com meus testes assíncronos. Sua capacidade de misturar testes seriais e paralelos é impressionante.
Certifique-se de ler o documento de orientação com cuidado, mas assim que conseguir entender, ele é flexível, poderoso e produz resultados agradáveis e limpos.
UPDATE: Também gostaria de incentivar as pessoas a verificar deve por sua afirma. Ele permite afirmações muito flexíveis, muito legíveis e é compatível com Expresso e Vows, e provavelmente com a maioria das outras estruturas de teste.
(Estou postando isso como uma resposta separada, caso as pessoas não percebam os comentários na resposta de Alfred.)
ATUALIZAÇÃO 1/7/2015: Desde o que vale a pena, mudei de Vows para Mocha e de Should para Chai. O Mocha agora tem muito mais suporte para testes assíncronos usando promessas, e o Chai permite várias opções de afirmação flexíveis, incluindo a expectAPI, para quem não gosta de modificar o protótipo do objeto.
shouldpega uma propriedade não enumerável nomeada shouldpara o Objectprotótipo, o que significa que todos os valores / objetos com os quais você está lidando parecem um pouco diferentes no tempo de teste e no tempo de produção. Embora isso provavelmente “funcione” na maioria dos casos, é, em princípio, uma má ideia modificar protótipos embutidos; fazê-lo apenas durante o teste parece errado. Tudo foi feito exclusivamente para que eles tenham uma boa sintaxe.
shouldsem estender Object.prototype(basta chamar require('should').noConflict()e usar o should.js como uma alternativa esperada.
Comecei a usar o Jasmine para meus testes de JavaScript especificamente porque é pequeno e é executado no navegador e no nó. Ele também possui uma API de relatórios e correspondências realmente sólida, para facilitar a integração com outras ferramentas no futuro. Ter uma estrutura de simulação de construção também é útil, pois é uma das primeiras coisas que eu adicionaria quando estava usando o qunit para TDD no navegador.
Se você deseja uma estrutura BDD verdadeira, talvez considere o Yadda . Ele se integra ao mocha, jasmine, nodeunit, qunit, zombie e casperjs, para suportar arquivos de recursos, por exemplo
Scenario: provides the version of all services
given service x is running
and service y is running
when I request the service versions
then service x should be version 0.0.1
and service y should be version 0.0.2Eu tenho usado o nodeunit e sua capacidade de trabalhar com funções assíncronas é razoavelmente direta.
Há uma boa explicação que deve deixar você pronto para usar a unidade de nó no blog dele .
[ Nota: a API foi alterada desde o post do blog - setUp(callback)e tearDown(callback)ambas recebem um retorno de chamada como argumento, que você precisa chamar quando a instalação / desmontagem estiver concluída. ]