Desarrollo impulsado por pruebas de meteoritos [cerrado]

No veo cómo hacer un desarrollo basado en pruebas en meteor.

No veo que se mencione en ninguna parte de la documentación o las preguntas frecuentes. No veo ningún ejemplo ni nada de eso.

Veo que algunos paquetes están usando Tinytest.

Necesitaría una respuesta de los desarrolladores, cuál es la hoja de ruta con respecto a esto. Algo parecido a:

• posible, sin documentación, descúbrelo tú mismo
• meteoro no está construido de una manera que pueda hacer aplicaciones comprobables
• esta es una característica planeada
• etc

Actualización 3 : a partir de Meteor 1.3, meteor incluye una guía de prueba con instrucciones paso a paso para la unidad, integración, aceptación y prueba de carga.

Actualización 2 : a partir del 9 de noviembre de 2015, Velocity ya no se mantiene . Xolv.io está centrando sus esfuerzos en Chimp , y el Meteor Development Group debe elegir un marco de prueba oficial .

Actualización : Velocity es la solución de prueba oficial de Meteor a partir de 0.8.1.

No se ha escrito mucho sobre las pruebas automatizadas con Meteor en este momento. Espero que la comunidad de Meteor evolucione las mejores prácticas de prueba antes de establecer nada en la documentación oficial. Después de todo, Meteor alcanzó 0.5 esta semana y las cosas todavía están cambiando rápidamente.

La buena noticia: puede utilizar las herramientas de prueba de Node.js con Meteor .

Para mi proyecto Meteor, ejecuto mis pruebas unitarias con Mocha usando Chai para las afirmaciones. Si no necesita el conjunto completo de funciones de Chai, le recomiendo usar should.js en su lugar. Solo tengo pruebas unitarias en este momento, aunque también puedes escribir pruebas de integración con Mocha.

Asegúrese de colocar sus pruebas en la carpeta "tests" para que Meteor no intente ejecutar sus pruebas.

Mocha es compatible con CoffeeScript , mi elección de lenguaje de programación para proyectos Meteor. Aquí hay un ejemplo de Cakefile con tareas para ejecutar sus pruebas de Mocha. Si está utilizando JS con Meteor, no dude en adaptar los comandos para un Makefile.

Sus modelos Meteor necesitarán una pequeña modificación para exponerse a Mocha, y esto requiere cierto conocimiento de cómo funciona Node.js. Piense que cada archivo Node.js se ejecuta dentro de su propio alcance. Meteor expone automáticamente objetos en diferentes archivos entre sí, pero las aplicaciones normales de Node, como Mocha, no hacen esto. Para que nuestros modelos sean probables por Mocha, exporte cada modelo de Meteor con el siguiente patrón 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?

... y en la parte superior de su prueba de Mocha, importe el modelo que desea probar:

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

¡Con eso, puede comenzar a escribir y ejecutar pruebas unitarias con su proyecto Meteor!

Hola a todos, checkout laika : todo el nuevo marco de prueba para meteor http://arunoda.github.io/laika/

Puede probar tanto el servidor como el cliente a la vez.

• Vea un ejemplo de laika aquí
• Consulte aquí las características
• Ver el concepto detrás de laika
• Ver repositorio de Github

Descargo de responsabilidad: soy el autor de Laika.

Me doy cuenta de que esta pregunta ya está respondida, pero creo que esto podría usar un poco más de contexto, en forma de una respuesta adicional que proporcione dicho contexto.

He estado haciendo un poco de desarrollo de aplicaciones con meteor, así como el desarrollo de paquetes, tanto implementando un paquete para el núcleo de meteoritos como para la atmósfera .

Parece que su pregunta podría ser en realidad una pregunta dividida en tres partes:

1. ¿Cómo se ejecuta todo el conjunto de pruebas de meteoritos?
2. ¿Cómo se pueden escribir y ejecutar pruebas para paquetes inteligentes individuales ?
3. ¿Cómo se pueden escribir y ejecutar pruebas para su propia aplicación?

Y también parece que puede haber una pregunta adicional en alguna parte: 4. ¿Cómo se puede implementar la integración continua para 1, 2 y 3?

He estado hablando y comencé a colaborar con Naomi Seyfer (@sixolet) en el equipo del núcleo de meteoritos para ayudar a obtener respuestas definitivas a todas estas preguntas en la documentación.

Había enviado una solicitud de extracción inicial que se dirigía a 1 y 2 al núcleo del meteorito: https://github.com/meteor/meteor/pull/573 .

También había respondido recientemente a esta pregunta: ¿Cómo se ejecutan las pruebas de meteoritos?

Creo que @Blackcoat definitivamente ha respondido 3, arriba.

En cuanto al bono, 4, sugeriría usar circleci.com al menos para hacer una integración continua para sus propias aplicaciones. Actualmente admiten el caso de uso que @Blackcoat había descrito. Tengo un proyecto en el que obtuve con éxito pruebas escritas en coffeescript para ejecutar pruebas unitarias con mocha, más o menos como lo describió @Blackcoat.

Para una integración continua en el núcleo de meteoritos y los paquetes inteligentes, Naomi Seyfer y yo estamos charlando con el fundador de circleci para ver si podemos implementar algo increíble en el corto plazo.

RTD ahora ha sido obsoleto y reemplazado por Velocity, que es el marco de prueba oficial para Meteor 1.0. La documentación es todavía relativamente nueva ya que Velocity está en un gran desarrollo. Puede encontrar más información sobre el repositorio de Velocity Github , la página de inicio de Velocity y el Manual de prueba de meteoritos (contenido pago)

Descargo de responsabilidad: soy uno de los miembros del equipo principal de Velocity y el autor del libro.

Echa un vistazo a la IDT, un marco de análisis completo para Meteor aquí rtd.xolv.io . Es compatible con Jasmine / Mocha / custom y funciona tanto con JS simple como con café. También incluye cobertura de prueba que combina la cobertura de unidad / servidor / cliente.

Y un proyecto de ejemplo aquí

Un blog para explicar las pruebas unitarias con Meteor aquí

Un enfoque de prueba de aceptación e2e usando Selenium WebdriverJS y Meteor aquí

Espero que ayude. Descargo de responsabilidad: soy el autor de RTD.

Usé mucho esta página y probé todas las respuestas, pero desde el punto de partida de mi principiante, las encontré bastante confusas. Una vez que tuve algún problema, me quedé desconcertado sobre cómo solucionarlo.

Esta solución es realmente simple para comenzar, si aún no está completamente documentada, por lo que la recomiendo para personas como yo que quieren hacer TDD pero no están seguras de cómo funcionan las pruebas en JavaScript y qué bibliotecas se conectan a qué:

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

Para su información, descubrí que también necesito usar el paquete Atmosphere del enrutador para hacer una ruta '/ tests' para ejecutar y mostrar los resultados de las pruebas, ya que no quería que saturara mi aplicación cada vez que se carga.

Sobre el uso de tinytest, es posible que desee echar un vistazo a esos recursos útiles:

1. Los conceptos básicos se explican en este screencast: https://www.eventedmind.com/feed/meteor-testing-packages-with-tinytest

2. Una vez que haya entendido la idea, querrá la documentación de la API pública para tinytest. Por ahora, la única documentación para eso está al final de la fuente del tinytestpaquete: https://github.com/meteor/meteor/tree/devel/packages/tinytest

3. Además, el screencast habla test-helpers, es posible que desee echar un vistazo a todos los ayudantes disponibles aquí: https://github.com/meteor/meteor/tree/devel/packages/test-helpers A menudo hay alguna documentación dentro de cada uno expediente

4. Profundizar en las pruebas existentes de los paquetes de meteoritos proporcionará muchos ejemplos. Una forma de hacer esto es realizar una búsqueda Tinytest.o test.en el directorio del paquete del código fuente de meteor

Las pruebas se convierten en una parte fundamental de Meteor en la próxima versión 1.3. La solución inicial se basa en Mocha y Chai.

Las discusiones originales sobre el diseño mínimo viable se pueden encontrar aquí y los detalles de la primera implementación se pueden encontrar aquí .

MDG ha producido los huesos iniciales de la documentación de la guía para las pruebas que se pueden encontrar aquí , y hay algunas pruebas de ejemplo aquí .

Este es un ejemplo de una prueba de publicación del enlace anterior:

  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();
    });
  });

Estoy haciendo pruebas funcionales / de integración con Meteor + Mocha en el navegador. Tengo algo parecido a lo siguiente (en coffeescript para una mejor legibilidad):

En el 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()

... y en el servidor:

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

Por supuesto, puede realizar las pruebas unitarias del lado del cliente de la misma manera. Sin embargo, para las pruebas de integración es bueno tener toda la infraestructura de Meteor.

Como dijo Blackcout, Velocity es el marco TDD oficial para Meteor. Pero en este momento la página web de velocity no ofrece una buena documentación. Así que te recomiendo que mires:

• Concepto detrás de la velocidad
• Tutorial paso a paso
• Y especialmente los ejemplos oficiales

Otra opción, que está fácilmente disponible desde 0.6.0, es ejecutar toda la aplicación a partir de paquetes inteligentes locales, con una cantidad mínima de código fuera de los paquetes para iniciar su aplicación (posiblemente invocando un paquete inteligente particular que es la base de su aplicación).

A continuación, puede aprovechar Tinytest de Meteor, que es ideal para probar aplicaciones de Meteor.

He estado usando xolvio: pepino y velocidad con éxito para hacer mis pruebas. Funciona muy bien y se ejecuta de forma continua, por lo que siempre puede ver que sus pruebas están pasando.

Meteoro + TheIntern

De alguna manera logré probar la aplicación Meteor con TheIntern.js.

Aunque es según mi necesidad. Pero todavía creo que puede llevar a alguien en la dirección correcta y estoy compartiendo lo que he hecho para resolver este problema.

Hay una executefunción que nos permite ejecutar código JS a través del cual podemos acceder al windowobjeto del navegador y, por lo tanto, Meteortambién.

Quiere saber más sobre ejecutar

Así es como se test suiteve mi para las pruebas funcionales

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 más, esta es mi esencia.

Nota: todavía estoy en una fase muy temprana con esta solución. No sé si puedo hacer pruebas complejas con esto o no. Pero estoy bastante seguro de ello.

La velocidad aún no está madura. Estoy enfrentando problemas de setTimeout para usar la velocidad. Para las pruebas unitarias del lado del servidor, puede utilizar este paquete .

Es más rápido que la velocidad. La velocidad requiere mucho tiempo cuando pruebo cualquier especificación con un inicio de sesión. Con el código Jasmine podemos probar cualquier método y publicación del lado del servidor.