Desenvolvimento orientado a testes de meteoros [fechado]

Não vejo como fazer o desenvolvimento orientado a testes em meteoros.

Não o vejo mencionado em nenhum lugar na documentação ou nas Perguntas frequentes. Não vejo exemplos ou algo assim.

Vejo que alguns pacotes estão usando o Tinytest.

Eu precisaria de resposta dos desenvolvedores, qual é o roteiro sobre isso. Algo ao longo das linhas de:

• possível, sem documentação, descubra você mesmo
• meteoro não é construído de maneira que você possa criar aplicativos testáveis
• isso é recurso planejado
• etc

Atualização 3 : A partir do Meteor 1.3, o meteoro inclui um guia de teste com instruções passo a passo para testes de unidade, integração, aceitação e carga.

Atualização 2 : em 9 de novembro de 2015, o Velocity não é mais mantido . O Xolv.io está concentrando seus esforços no Chimp , e o Grupo de Desenvolvimento de Meteoros deve escolher uma estrutura de teste oficial .

Atualização : Velocity é a solução de teste oficial do Meteor a partir de 0.8.1.

Não se escreveu muito sobre testes automatizados com o Meteor no momento. Espero que a comunidade Meteor desenvolva as melhores práticas de teste antes de estabelecer qualquer coisa na documentação oficial. Afinal, o Meteor chegou a 0,5 nesta semana, e as coisas ainda estão mudando rapidamente.

A boa notícia: você pode usar as ferramentas de teste do Node.js. com o Meteor .

Para o meu projeto Meteor, eu executo meus testes de unidade com o Mocha usando o Chai como asserções. Se você não precisa do conjunto completo de recursos do Chai, recomendo usar o should.js . No momento, só tenho testes de unidade, embora você possa escrever testes de integração com o Mocha.

Certifique-se de colocar seus testes na pasta "testes" para que Meteor não tentativa de executar seus testes.

Mocha suporta CoffeeScript , minha escolha de linguagem de script para projetos Meteor. Aqui está um exemplo de Cakefile com tarefas para executar seus testes Mocha. Se você estiver usando JS com Meteor, sinta-se à vontade para adaptar os comandos para um Makefile.

Seus modelos do Meteor precisarão de um pouco de modificação para se expor ao Mocha, e isso requer algum conhecimento de como o Node.js. funciona. Pense em cada arquivo Node.js como sendo executado dentro de seu próprio escopo. O Meteor expõe automaticamente objetos em arquivos diferentes entre si, mas aplicativos Node comuns - como o Mocha - não fazem isso. Para tornar nossos modelos testáveis ​​pelo Mocha, exporte cada modelo do Meteor com o seguinte padrão CoffeeScript:

# Export our class to Node.js when running
# other modules, e.g. our Mocha tests
#
# Place this at the bottom of our Model.coffee
# file after our Model class has been defined.
exports.Model = Model unless Meteor?

... e na parte superior do seu teste Mocha, importe o modelo que você deseja testar:

# Need to use Coffeescript's destructuring to reference
# the object bound in the returned scope
# http://coffeescript.org/#destructuring
{Model} = require '../path/to/model'

Com isso, você pode começar a escrever e executar testes de unidade com seu projeto Meteor!

Olá, tudo checkout laika - toda a nova estrutura de testes para meteoros http://arunoda.github.io/laika/

Você pode testar o servidor e o cliente de uma só vez.

• Veja alguns exemplos de laika aqui
• Veja aqui para recursos
• Veja o conceito por trás da laika
• Consulte Repositório do Github

Disclaimer: Eu sou o autor de Laika.

Percebo que essa pergunta já foi respondida, mas acho que isso poderia usar um pouco mais de contexto, na forma de uma resposta adicional, fornecendo o referido contexto.

Venho desenvolvendo alguns aplicativos com meteoro, bem como desenvolvimento de pacotes, implementando um pacote para o núcleo do meteoro e para a atmosfera .

Parece que sua pergunta pode ser realmente uma questão em três partes:

1. Como se executa todo o conjunto de testes de meteoros?
2. Como se escreve e executa testes para pacotes inteligentes individuais ?
3. Como alguém escreve e executa testes para seu próprio aplicativo?

E também parece que pode haver uma pergunta bônus em algum lugar: 4. Como alguém pode implementar a integração contínua para 1, 2 e 3?

Conversei e comecei a colaborar com Naomi Seyfer (@sixolet) na equipe principal de meteoros para ajudar a obter respostas definitivas para todas essas perguntas na documentação.

Enviei uma solicitação de recebimento inicial endereçando 1 e 2 ao núcleo do meteoro: https://github.com/meteor/meteor/pull/573 .

Também respondi recentemente a esta pergunta: Como você executa os testes de meteoros?

Eu acho que a @Blackcoat respondeu definitivamente a 3 acima.

Quanto ao bônus 4, sugiro usar o circleci.com pelo menos para fazer a integração contínua de seus próprios aplicativos. Atualmente, eles suportam o caso de uso que a @Blackcoat havia descrito. Eu tenho um projeto no qual obtive testes escritos com sucesso em coffeescript para executar testes de unidade com mocha, como o @Blackcoat havia descrito.

Para integração contínua no núcleo de meteoros e pacotes inteligentes, Naomi Seyfer e eu estamos conversando com o fundador do circleci para ver se podemos conseguir algo incrível implementado no curto prazo.

O RTD agora foi descontinuado e substituído pelo Velocity, que é a estrutura de teste oficial do Meteor 1.0. A documentação ainda é relativamente nova, pois o Velocity está em desenvolvimento pesado. Você pode encontrar mais informações no repositório do Velocity Github , na página inicial do Velocity e no manual do Meteor Testing (conteúdo pago)

Isenção de responsabilidade: sou um dos principais membros da equipe do Velocity e o autor do livro.

Confira IDT, uma estrutura de teste completo para Meteor aqui rtd.xolv.io . Ele suporta Jasmine / Mocha / custom e funciona com JS e café simples. Também inclui cobertura de teste que combina cobertura de unidade / servidor / cliente.

E um exemplo de projeto aqui

Um blog para explicar o teste de unidade com o Meteor aqui

Uma abordagem de teste de aceitação do e2e usando Selenium WebdriverJS e Meteor aqui

Espero que ajude. Disclaimer: Eu sou o autor da RTD.

Eu usei bastante esta página e tentei todas as respostas, mas do ponto de partida para iniciantes, achei-as bastante confusas. Depois que tive algum problema, fiquei confuso sobre como consertá-los.

Como é fácil começar essa solução, se ainda não estiver totalmente documentada, recomendo para pessoas como eu que desejam fazer TDD, mas não sabem ao certo como o teste em JavaScript funciona e quais bibliotecas se encaixam no que:

https://github.com/mad-eye/meteor-mocha-web

Para sua informação, descobri que também preciso usar o pacote Atmosphere do roteador para fazer uma rota '/ tests' para executar e exibir os resultados dos testes, pois eu não queria que ele bagunçasse meu aplicativo toda vez que ele carregasse.

Sobre o uso do tinytest, você pode dar uma olhada nesses recursos úteis:

1. Os princípios básicos são explicados neste screencast: https://www.eventedmind.com/feed/meteor-testing-packages-with-tinytest

2. Depois de entender a idéia, você precisará da documentação pública da API tinytest. Por enquanto, a única documentação para isso está no final da fonte do tinytestpacote: https://github.com/meteor/meteor/tree/devel/packages/tinytest

3. Além disso, o screencast fala sobre test-helpers, você pode dar uma olhada em todos os auxiliares disponíveis aqui: https://github.com/meteor/meteor/tree/devel/packages/test-helpers Geralmente há alguma documentação dentro de cada Arquivo

4. Cavar nos testes existentes dos pacotes de meteoros fornecerá muitos exemplos. Uma maneira de fazer isso é fazer uma pesquisa Tinytest.ou test.no diretório de pacotes do código-fonte do meteoro

Os testes se tornam uma parte essencial do Meteor na próxima versão 1.3. A solução inicial é baseada em Mocha e Chai.

As discussões originais sobre o design mínimo viável podem ser encontradas aqui e os detalhes da primeira implementação podem ser encontrados aqui .

Os ODM produziram os ossos iniciais da documentação do guia para os testes, que podem ser encontrados aqui , e existem alguns exemplos de testes aqui .

Este é um exemplo de teste de publicação no link acima:

  it('sends all todos for a public list when logged in', (done) => {
    const collector = new PublicationCollector({userId});
    collector.collect('Todos.inList', publicList._id, (collections) => {
      chai.assert.equal(collections.Todos.length, 3);
      done();
    });
  });

Estou fazendo funcional / integração testes com o Meteor + Mocha no navegador. Eu tenho algo parecido com o seguinte (em coffeescript para melhor legibilidade):

No cliente ...

Meteor.startup ->
    Meteor.call 'shouldTest', (err, shouldTest) ->
        if err? then throw err
        if shouldTest then runTests()

# Dynamically load and run mocha. I factored this out in a separate method so
# that I can (re-)run the tests from the console whenever I like.
# NB: This assumes that you have your mocha/chai scripts in .../public/mocha.
# You can point to a CDN, too.
runTests = ->
    $('head').append('<link href="https://stackoverflow.com/mocha/mocha.css" rel="stylesheet" />')
    $.getScript '/mocha/mocha.js', ->
      $.getScript '/mocha/chai.js', ->
        $('body').append('<div id="mocha"> </div>')
        chai.should() # ... or assert or explain ...
        mocha.setup 'bdd'
        loadSpecs() # This function contains your actual describe(), etc. calls.
        mocha.run()

... e no servidor:

Meteor.methods 'shouldTest': -> true unless Meteor.settings.noTests  # ... or whatever.

É claro que você pode fazer seus testes de unidade do lado da cliente da mesma maneira. Para testes de integração, é bom ter toda a infraestrutura do Meteor por perto.

Como Blackcout disse, o Velocity é a estrutura oficial de TDD do Meteor. Mas, neste momento, a página da velocidade não oferece boa documentação. Então eu recomendo que você assista:

• Conceito por trás da velocidade
• Tutorial passo a passo
• E especialmente os exemplos oficiais

Outra opção, disponibilizada facilmente desde a versão 0.6.0, é executar todo o aplicativo a partir de pacotes inteligentes locais, com uma quantidade mínima de código fora dos pacotes para inicializá-lo (possivelmente invocando um pacote inteligente específico que é a base do seu aplicativo). aplicativo).

Você pode aproveitar o Tinytest do Meteor, o que é ótimo para testar aplicativos Meteor.

Eu tenho usado com sucesso xolvio: pepino e velocidade para fazer meus testes. Funciona muito bem e é executado continuamente para que você sempre possa ver que seus testes estão passando.

Meteor + TheIntern

De alguma forma, consegui testar o aplicativo Meteor com TheIntern.js.

Embora seja conforme minha necessidade. Mas ainda acho que isso pode levar alguém à direção certa e estou compartilhando o que fiz para resolver esse problema.

Existe uma executefunção que nos permite executar o código JS através do qual podemos acessar o windowobjeto do navegador e, portanto, Meteortambém.

Deseja saber mais sobre execute

É assim que minha test suiteaparência para testes funcionais

define(function (require) {
    var registerSuite = require('intern!object');
    var assert = require('intern/chai!assert');
    registerSuite({
        name: 'index',

        'greeting form': function () {
            var rem = this.remote;
            return this.remote
                .get(require.toUrl('localhost:3000'))
                .setFindTimeout(5000)
                .execute(function() {
                        console.log("browser window object", window)
                        return Products.find({}).fetch().length
                    })
                .then(function (text) {
                    console.log(text)
                    assert.strictEqual(text, 2,
                        'Yes I can access Meteor and its Collections');
                });
        }
    });
});

Para saber mais, esta é minha essência

Nota: Ainda estou em uma fase muito inicial com esta solução. Não sei se posso fazer testes complexos com isso ou não. Mas estou bastante confiante sobre isso.

A velocidade ainda não está madura. Estou enfrentando problemas de setTimeout para usar velocidade. Para teste de unidade no servidor, você pode usar este pacote .

É mais rápido que a velocidade. O Velocity exige um tempo enorme quando eu testo qualquer especificação com um login. Com o código Jasmine, podemos testar qualquer método e publicação do lado do servidor.