Desarrollo impulsado por pruebas de meteoritos [cerrado]

120

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
Rubycut
fuente
4
Eche un vistazo al blog xolv.io , como se menciona a continuación, hay ejemplos de cómo hacer la unidad adecuada + TDD de extremo a extremo usando Meteor.
Xolv.io
Por el tono de tu pregunta, parece que tienes la impresión de que faltan muchas cosas en Meteor. En cierto modo lo es, pero atmosfera.meteor.com tiene paquetes para hacer la mayoría de las cosas que se te ocurran al agrupar las bibliotecas JS existentes en un formato listo para usar. Podría estar más vinculado a meteor.com, en mi humilde opinión.
pipedreambomb
5
deberías pagar laika - arunoda.github.io/laika
Arunoda Susiripala
1
Las pruebas de meteoritos son actualmente un desastre. Consulte trello.com/c/BQ3gu0no/12-official-testing-framework para obtener actualizaciones.
Andrew Mao

Respuestas:

83

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!

Abrigo negro
fuente
2
Probé esto y encontré problemas cuando mi código bajo prueba usa alguna Meteor.whateverfunción. Meteor tiene errores indefinidos. ¿Hay alguna manera de requerir que Meteor explícitamente evite esto?
Christian Schlensker
2
Christian, el enfoque descrito en mi respuesta está incompleto en este momento, ya que no ejecuta una instancia completa de su aplicación Meteor. Como resultado, el Meteorobjeto es inaccesible, al igual que cualquier dependencia del modelo expuesta por Meteor. Mejorar este proceso implicará crear una instancia del entorno de la aplicación dentro de Mocha y exponer el Meteorobjeto a sus pruebas. Me aseguraré de actualizar esta respuesta una vez que tenga una solución de prueba más completa. Mientras tanto, no dude en ponerse en contacto conmigo con cualquier pregunta o sugerencia de mejoras.
Blackcoat
@ChristianSchlensker: Si usa Mocha para pruebas funcionales / unitarias en el lado del cliente, entonces tiene objetos Meteor disponibles. Vea el código de muestra en mi respuesta a continuación.
Jerico
@jerico Sí, eso se ve bien, no funcionaría para ninguna de las clases del lado del servidor. También me gusta tener mocha: ver funcionando en todas las pruebas unitarias todo el tiempo. Se ejecutan tan rápido en el lado del servidor que es una respuesta de prueba realmente agradable.
Christian Schlensker
1
a partir de 1.3, las pruebas ahora están disponibles en meteor, consulte guide.meteor.com
bigmadwolf
44

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.

Descargo de responsabilidad: soy el autor de Laika.

Arunoda Susiripala
fuente
Hola Arunoda. Aprecio su arduo trabajo para Meteor. Sin embargo, aquí en StackOverflow debe señalar como descargo de responsabilidad que usted es el que está detrás de laika.
finalmente,
5
¿Es esa la forma de hacerlo?
Arunoda Susiripala
1
Gracias por su cooperación.
finalmente,
14

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.

entusiasta
fuente
12

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.

Xolv.io
fuente
6

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.

bomba de agua
fuente
1
También puede utilizar meteor-mocha-webcon mocha-phantomjspara automatizar las pruebas y para CI. Es lo que usamos. Divulgación completa: soy uno de los mantenedores de meteor-mocha-web.
jagill
6

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

William Ledoux
fuente
5

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

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.

Jerico
fuente
Por cierto: esta solución para esperar elementos DOM es útil cuando se realizan pruebas funcionales en el cliente Meteor con jQuery.
Jerico
2

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.

matb33
fuente
0

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.

Philip Beadle
fuente
0

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.

Harpreet Singh
fuente
0

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.

Zahed
fuente