Meteor test driven development [chiuso]

Non vedo come eseguire lo sviluppo test driven in meteor.

Non lo vedo menzionato da nessuna parte nella documentazione o nelle FAQ. Non vedo esempi o cose del genere.

Vedo che alcuni pacchetti utilizzano Tinytest.

Avrei bisogno di una risposta da parte degli sviluppatori, qual è la roadmap in merito. Qualcosa sulla falsariga di:

• possibile, nessuna documentazione, scoprilo da solo
• meteor non è costruito in modo da poter creare app testabili
• questa è una funzionalità pianificata
• eccetera

Aggiornamento 3 : a partire da Meteor 1.3, meteor include una guida ai test con istruzioni dettagliate per unità, integrazione, accettazione e test di carico.

Aggiorna 2 : dal 9 novembre 2015, Velocity non è più mantenuto . Xolv.io sta concentrando i propri sforzi su Chimp e il Meteor Development Group deve scegliere un framework di test ufficiale .

Aggiornamento : Velocity è la soluzione di test ufficiale di Meteor a partire dalla 0.8.1.

Al momento non è stato scritto molto sui test automatizzati con Meteor. Mi aspetto che la comunità di Meteor evolva testando le migliori pratiche prima di stabilire qualcosa nella documentazione ufficiale. Dopotutto, Meteor ha raggiunto 0,5 questa settimana e le cose stanno ancora cambiando rapidamente.

Le buone notizie: puoi utilizzare gli strumenti di test di Node.js con Meteor .

Per il mio progetto Meteor, eseguo i miei unit test con Mocha usando Chai per le asserzioni. Se non hai bisogno del set completo di funzionalità di Chai, ti consiglio di usare invece should.js . Al momento ho solo unit test, anche se puoi scrivere test di integrazione anche con Mocha.

Assicurati di inserire i tuoi test nella cartella "tests" in modo che Meteor non tenti di eseguire i tuoi test.

Mocha supporta CoffeeScript , la mia scelta di linguaggio di scripting per i progetti Meteor. Ecco un esempio di Cakefile con attività per eseguire i tuoi test Mocha. Se stai usando JS con Meteor, sentiti libero di adattare i comandi per un Makefile.

I tuoi modelli Meteor avranno bisogno di una leggera modifica per esporsi a Mocha, e questo richiede una certa conoscenza di come funziona Node.js. Pensa a ogni file Node.js come eseguito all'interno del proprio ambito. Meteor espone automaticamente gli oggetti in file differenti l'uno all'altro, ma le normali applicazioni Node, come Mocha, non lo fanno. Per rendere i nostri modelli testabili da Mocha, esporta ogni modello Meteor con il seguente pattern 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 nella parte superiore del tuo test Mocha, importa il modello che desideri testare:

# 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 ciò, puoi iniziare a scrivere ed eseguire unit test con il tuo progetto Meteor!

Ciao a tutti, controlla laika , il nuovo framework di test per meteor http://arunoda.github.io/laika/

Puoi testare sia il server che il client contemporaneamente.

• Vedi alcuni esempi di laika qui
• Vedi qui per le caratteristiche
• Vedi il concetto dietro laika
• Vedi Github Repository

Disclaimer: sono l'autore di Laika.

Mi rendo conto che questa domanda ha già una risposta, ma penso che questo potrebbe utilizzare un po 'più di contesto, sotto forma di una risposta aggiuntiva che fornisce detto contesto.

Ho sviluppato alcune app con meteor, oltre allo sviluppo di pacchetti, sia implementando un pacchetto per meteor core che per l' atmosfera .

Sembra che la tua domanda potrebbe essere in realtà una domanda in tre parti:

1. Come si esegue l'intera suite di test meteorologici?
2. Come si scrivono ed eseguono test per singoli pacchetti intelligenti ?
3. Come si scrive ed esegue test per la propria applicazione?

E sembra anche che ci possa essere una domanda bonus da qualche parte: 4. Come si può implementare l'integrazione continua per 1, 2 e 3?

Ho parlato e iniziato a collaborare con Naomi Seyfer (@sixolet) nel team principale di meteor per aiutare a ottenere risposte definitive a tutte queste domande nella documentazione.

Avevo inviato una richiesta di pull iniziale indirizzando 1 e 2 a meteor core: https://github.com/meteor/meteor/pull/573 .

Recentemente avevo anche risposto a questa domanda: come si eseguono i test delle meteoriti?

Penso che @Blackcoat abbia risposto definitivamente a 3, sopra.

Per quanto riguarda il bonus, 4, suggerirei di utilizzare circleci.com almeno per fare un'integrazione continua per le proprie app. Attualmente supportano il caso d'uso descritto da @Blackcoat. Ho un progetto in cui ho ottenuto con successo test scritti in coffeescript per eseguire unit test con mocha, più o meno come aveva descritto @Blackcoat.

Per una continua integrazione su Meteor Core e pacchetti intelligenti, Naomi Seyfer e io stiamo chattando con il fondatore di circleci per vedere se possiamo ottenere qualcosa di fantastico implementato a breve termine.

RTD è stato ora deprecato e sostituito da Velocity, che è il framework di test ufficiale per Meteor 1.0. La documentazione è ancora relativamente nuova poiché Velocity è in forte sviluppo. Puoi trovare ulteriori informazioni sul repository Velocity Github , sulla pagina iniziale di Velocity e sul manuale di test di meteoriti (contenuto a pagamento)

Disclaimer: sono uno dei membri principali del team di Velocity e l'autore del libro.

Scopri RST, un ambiente di test completo per Meteor qui rtd.xolv.io . Supporta Jasmine / Mocha / personalizzato e funziona sia con JS normale che con caffè. Include anche la copertura del test che combina la copertura dell'unità / server / client.

E un progetto di esempio qui

Un blog per spiegare i test di unità con Meteor qui

Un approccio di test di accettazione e2e utilizzando Selenium WebdriverJS e Meteor qui

Spero che aiuti. Disclaimer: sono l'autore di RTD.

Ho usato molto questa pagina e ho provato tutte le risposte, ma dal punto di partenza del mio principiante le ho trovate abbastanza confuse. Una volta che ho avuto problemi, ero sconcertato su come risolverli.

Questa soluzione è davvero semplice per iniziare, se non ancora completamente documentata, quindi la consiglio a persone come me che vogliono fare TDD ma non sono sicure di come funziona il test in JavaScript e quali librerie si collegano a cosa:

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

Cordiali saluti, ho scoperto che devo anche utilizzare il pacchetto Atmosphere del router per creare un percorso "/ tests" per eseguire e visualizzare i risultati dei test, poiché non volevo che ingombrasse la mia app ogni volta che viene caricata.

Per quanto riguarda l'utilizzo di tinytest, potresti dare un'occhiata a quelle risorse utili:

1. Le basi sono spiegate in questo screencast: https://www.eventedmind.com/feed/meteor-testing-packages-with-tinytest

2. Una volta compresa l'idea, ti consigliamo la documentazione API pubblica per tinytest. Per ora, l'unica documentazione per questo è alla fine del codice sorgente del tinytestpacchetto: https://github.com/meteor/meteor/tree/devel/packages/tinytest

3. Inoltre, di cui parla lo screencast test-helpers, potresti voler dare un'occhiata a tutti gli helper disponibili qui: https://github.com/meteor/meteor/tree/devel/packages/test-helpers C'è spesso della documentazione all'interno di ciascuno file

4. Scavare nei test esistenti dei pacchetti di meteoriti fornirà molti esempi. Un modo per farlo è cercare Tinytest.o test.nella directory del pacchetto del codice sorgente di meteor

I test diventano una parte fondamentale di Meteor nella prossima versione 1.3. La soluzione iniziale è basata su Mocha e Chai.

Le discussioni originali sul progetto minimo fattibile possono essere trovate qui e i dettagli della prima implementazione possono essere trovati qui .

MDG ha prodotto le ossa iniziali della documentazione guida per il test che può essere trovato qui , e ci sono alcuni test di esempio qui .

Questo è un esempio di un test di pubblicazione dal collegamento sopra:

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

Sto eseguendo test funzionali / di integrazione con Meteor + Mocha nel browser. Ho qualcosa sulla falsariga di quanto segue (in coffeescript per una migliore leggibilità):

Sul 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 sul server:

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

Ovviamente puoi eseguire i test di unità lato client allo stesso modo. Tuttavia, per i test di integrazione è bello avere a disposizione tutta l'infrastruttura di Meteor.

Come ha detto Blackcout, Velocity è il framework TDD ufficiale per Meteor. Ma in questo momento la pagina web di velocity non offre una buona documentazione. Quindi ti consiglio di guardare:

• Concetto alla base della velocità
• Tutorial passo passo
• E specialmente gli esempi ufficiali

Un'altra opzione, resa facilmente disponibile dalla 0.6.0, è quella di eseguire l'intera app da pacchetti intelligenti locali, con una quantità minima di codice al di fuori dei pacchetti per avviare l'app (possibilmente invocando un particolare pacchetto intelligente che è la base del tuo app).

Puoi quindi sfruttare Tinytest di Meteor, che è ottimo per testare le app Meteor.

Ho utilizzato con successo xolvio: cetriolo e velocità per eseguire i miei test. Funziona davvero bene e funziona continuamente, così puoi sempre vedere che i tuoi test stanno passando.

Meteor + TheIntern

In qualche modo sono riuscito a testare l'applicazione Meteor con TheIntern.js.

Anche se è secondo le mie necessità. Ma penso ancora che possa portare qualcuno nella giusta direzione e condivido ciò che ho fatto per risolvere questo problema.

C'è una executefunzione che ci permette di eseguire codice JS attraverso il quale possiamo accedere windowall'oggetto browser e quindi Meteoranche.

Vuoi saperne di più sull'esecuzione

Ecco come il mio test suiteaspetto per i test funzionali

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

Per saperne di più, questo è il mio succo

Nota: sono ancora nella fase iniziale con questa soluzione. Non so se posso fare test complessi con questo o no. Ma ne sono abbastanza fiducioso.

La velocità non è ancora matura. Sto affrontando problemi di setTimeout per utilizzare la velocità. Per i test di unità lato server è possibile utilizzare questo pacchetto .

È più veloce della velocità. La velocità richiede molto tempo quando provo qualsiasi specifica con un accesso. Con il codice Jasmine possiamo testare qualsiasi metodo e pubblicazione lato server.