tdd - Desarrollo impulsado por la prueba de meteoritos

Question

No veo cómo hacer un desarrollo impulsado por prueba en meteoro.

No lo veo mencionado en ninguna parte de la documentación o preguntas frecuentes. No veo ningún ejemplo ni nada de eso.

Veo que algunos paquetes están usando Tinytest.

Necesitaría la respuesta de los desarrolladores, ¿cuál es la hoja de ruta con respecto a esto? Algo como:

• posible, sin documentación, descárguelo usted mismo
• meteor no está construido de forma que puedas hacer aplicaciones comprobables
• esta es una función planificada
• etc

Answer 1

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

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

Answer 2

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="/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, usted puede hacer su prueba de unidad del lado del cliente de la misma manera. Sin embargo, para las pruebas de integración es bueno tener toda la infraestructura de Meteor.

Answer 3

He estado usando con éxito xolvio: pepino y velocidad para hacer mi prueba. Funciona muy bien y funciona continuamente para que siempre pueda ver que sus pruebas están pasando.

Answer 4

Hola, todos los arunoda.github.io/laika checkout arunoda.github.io/laika : el nuevo framework de pruebas para meteoro arunoda.github.io/laika

Puede probar tanto el servidor como el cliente de una vez.

• Vea algún ejemplo de laika aquí
• Vea aquí para las features
• Ver concepto detrás de laika
• Ver Repositorio de Github

Descargo de responsabilidad: soy el autor de Laika.

Answer 5

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

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

Answer 6

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

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

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

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

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

Answer 7

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

He estado desarrollando aplicaciones con meteoro, así como también desarrollo de paquetes, implementando un paquete para el núcleo del meteorito, así como para la atmosphere .

Parece que tu pregunta podría ser una pregunta en tres partes:

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

Y, también parece que puede haber una pregunta extra en algún lugar: 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 central de meteoritos para ayudar a obtener respuestas definitivas a todas estas preguntas en la documentación.

Presenté una solicitud de extracción inicial dirigiéndose a 1 y 2 a Meteor Core: https://github.com/meteor/meteor/pull/573 .

También recientemente respondí esta pregunta: ¿cómo se ejecutan las pruebas de meteoritos?

Creo que @Blackcoat definitivamente ha respondido 3, arriba.

En cuanto a la bonificación, 4, sugiero 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 pruebas escritas en coffeescript para ejecutar pruebas unitarias con mocha, casi como describió @Blackcoat.

Para una integración continua en Meteor Core y paquetes inteligentes, Naomi Seyfer y yo estamos conversando con el fundador de Cirleci para ver si podemos implementar algo increíble a corto plazo.

Answer 8

Otra opción, disponible fácilmente desde 0.6.0, es ejecutar toda su aplicación fuera de los 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 Meteor''s Tinytest, que es ideal para probar aplicaciones Meteor.

Answer 9

RTD ahora ha sido obsoleto y reemplazado por Velocity, que es el marco de prueba oficial para Meteor 1.0. La documentación es relativamente nueva ya que Velocity está en desarrollo. Puede encontrar más información sobre el repositorio 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 principales del equipo de Velocity y el autor del libro.

Consulte RTD, un marco de prueba completo para Meteor aquí rtd.xolv.io. Es compatible con Jasmine / Mocha / custom y funciona tanto con JS simple como con café. Incluye también cobertura de prueba que combina cobertura de unidad / servidor / cliente.

Y un ejemplo de proyecto here

Un blog para explicar las pruebas unitarias con Meteor here

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

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

Answer 10

Sobre el uso de tinytest, es posible que desee echarle 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 API pública para tinytest . Por ahora, la única documentación disponible está al final de la fuente del paquete más tinytest : https://github.com/meteor/meteor/tree/devel/packages/tinytest

3. Además, el screencast habla sobre los asistentes de 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 algunos documentación dentro de cada archivo

4. Excavar en las pruebas existentes de los paquetes de meteoros proporcionará muchos ejemplos. Una forma de hacerlo es realizar una búsqueda de Tinytest. o test. en el directorio del paquete del código fuente del meteoro

Answer 11

Utilicé esta página mucho e intenté 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 solucionarlos.

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

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

FYI, 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 mi aplicación se llenara cada vez que se carga.

Answer 12

Actualización 3 : a partir del Meteor 1.3, el meteoro incluye una guía de prueba con instrucciones paso a paso para 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 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 Meteor desarrolle mejores prácticas de prueba antes de establecer algo 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.

Las buenas noticias: puedes usar las herramientas de prueba de Node.js con Meteor .

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

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

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

Sus modelos Meteor necesitarán un poco de modificación para exponerse a Mocha, y esto requiere cierto conocimiento de cómo funciona Node.js. Piense en cada archivo Node.js como ejecutado dentro de su propio alcance. Meteor expone automáticamente los objetos en diferentes archivos, pero las aplicaciones normales de Node, como Mocha, no hacen esto. Para que nuestros modelos sean comprobables por Mocha, export cada modelo de Meteor con el siguiente patrón de 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 tu prueba de Mocha, importa el modelo que deseas 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, puedes comenzar a escribir y ejecutar pruebas unitarias con tu proyecto Meteor!

Answer 13

Meteor + TheIntern

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

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

Hay una función de execute que nos permite ejecutar el código JS a través del cual podemos acceder al objeto de la window navegador y, por lo tanto, también a Meteor .

¿Quieres saber más acerca de execute

Así es como mi test suite busca 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 gist

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 eso.