web-dev-qa-db-fra.com

Développement piloté par Meteor

Je ne vois pas comment faire du développement piloté par les tests dans météore.

Je ne le vois mentionné nulle part dans la documentation ou la FAQ. Je ne vois aucun exemple ou quelque chose comme ça.

Je vois que certains packages utilisent Tinytest.

J'aurais besoin d'une réponse des développeurs, quelle est la feuille de route à ce sujet. Quelque chose dans le sens de:

  • possible, pas de documentation, devinez vous-même
  • météore n'est pas construit de manière à ce que vous puissiez créer des applications testables
  • c'est une fonctionnalité planifiée
  • etc
120
Rubycut

Mise à jour 3 : à partir de Meteor 1.3, le météore comprend un guide de test avec des instructions pas à pas pour l'unité, l'intégration, l'acceptation et les tests de charge.

Mise à jour 2 : Depuis le 9 novembre 2015, la vitesse n'est plus maintenue . Xolv.io concentre ses efforts sur Chimp , et le Meteor Development Group doit choisir un cadre de test officiel .

Mise à jour : Velocity is Meteor official testing solution as of 0.8.1.


À l'heure actuelle, peu de choses ont été écrites sur les tests automatisés avec Meteor. Je m'attends à ce que la communauté Meteor fasse évoluer les meilleures pratiques de test avant d'établir quoi que ce soit dans la documentation officielle. Après tout, Meteor a atteint 0,5 cette semaine, et les choses évoluent encore rapidement.

La bonne nouvelle: vous pouvez utiliser outils de test Node.js avec Meteor .

Pour mon projet Meteor, je lance mes tests unitaires avec Mocha en utilisant Chai pour les assertions. Si vous n'avez pas besoin de l'ensemble des fonctionnalités de Chai, je recommande d'utiliser should.js à la place. Je n'ai que des tests unitaires pour le moment, bien que vous puissiez également écrire des tests d'intégration avec Mocha.

Assurez-vous de placez vos tests dans le dossier "tests" afin que Meteor n'essaye pas d'exécuter vos tests.

Mocha prend en charge CoffeeScript , mon choix de langage de script pour les projets Meteor. Voici un exemple de Cakefile avec des tâches pour exécuter vos tests Mocha. Si vous utilisez JS avec Meteor, n'hésitez pas à adapter les commandes d'un Makefile.

Vos modèles Meteor auront besoin d'une légère modification pour s'exposer à Mocha, et cela nécessite une certaine connaissance du fonctionnement de Node.js. Considérez chaque fichier Node.js comme étant exécuté dans sa propre portée. Meteor expose automatiquement les objets de différents fichiers les uns aux autres, mais les applications ordinaires Node - comme Mocha) ne le font pas. Pour rendre nos modèles testables par Mocha, export each Modèle Meteor avec le modèle CoffeeScript suivant:

# 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?

... et en haut de votre test Mocha, importez le modèle que vous souhaitez tester:

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

Avec cela, vous pouvez commencer à écrire et à exécuter des tests unitaires avec votre projet Meteor!

83
Blackcoat

Salut à tous checkout laika - le tout nouveau cadre de test pour les météores http://arunoda.github.io/laika/

Vous pouvez tester à la fois le serveur et le client.

Avertissement: je suis l'auteur de Laika.

44

Je me rends compte que cette question est déjà répondue, mais je pense que cela pourrait utiliser un peu plus de contexte, sous la forme d'une réponse supplémentaire fournissant ledit contexte.

J'ai fait du développement d'applications avec meteor, ainsi que le développement de packages, à la fois en implémentant un package pour meteor core, ainsi que pour atmosphere .

Il semble que votre question soit en fait une question en trois parties:

  1. Comment exécuter toute la suite de tests de météores?
  2. Comment écrire et exécuter des tests pour des individus packages intelligents ?
  3. Comment écrire et exécuter des tests pour sa propre application?

Et, il semble également qu'il puisse y avoir une question bonus quelque part: 4. Comment peut-on implémenter une intégration continue pour 1, 2 et 3?

J'ai parlé et commencé à collaborer avec Naomi Seyfer (@sixolet) sur le météore équipe principale pour aider à obtenir des réponses définitives à toutes ces questions dans la documentation.

J'avais soumis une demande de pull initiale adressant 1 et 2 au noyau de météore: https://github.com/meteor/meteor/pull/57 .

J'avais également récemment répondu à cette question: Comment exécutez-vous les tests des météores?

Je pense que @Blackcoat a définitivement répondu 3, ci-dessus.

Quant au bonus, 4, je suggère d'utiliser circleci.com au moins pour faire une intégration continue pour vos propres applications. Ils prennent actuellement en charge le cas d'utilisation décrit par @Blackcoat. J'ai un projet dans lequel j'ai réussi à obtenir des tests écrits en coffeescript pour exécuter des tests unitaires avec du moka, à peu près comme l'avait décrit @Blackcoat.

Pour une intégration continue sur le noyau de météores et les packages intelligents, Naomi Seyfer et moi discutons avec le fondateur de circleci pour voir si nous pouvons mettre en œuvre quelque chose de génial à court terme.

14
zealoushacker

RTD est désormais obsolète et remplacé par Velocity, qui est le cadre de test officiel de Meteor 1.0. La documentation est encore relativement récente car Velocity est en cours de développement. Vous pouvez trouver plus d'informations sur le Velocity Github repo , le Velocity Homepage et The Meteor Testing Manual (contenu payant)

Avertissement: je suis l'un des principaux membres de l'équipe de Velocity et l'auteur du livre.


Découvrez RTD, un framework de test complet pour Meteor ici rtd.xolv.io . Il prend en charge Jasmine/Mocha/personnalisé et fonctionne à la fois avec du JS ordinaire et du café. Il comprend également une couverture de test qui combine une couverture unité/serveur/client.

Et un exemple de projet ici

Un blog pour expliquer les tests unitaires avec Meteor ici

Une approche de test d'acceptation e2e utilisant Selenium WebdriverJS et Meteor ici

J'espère que ça t'as aidé. Avertissement: je suis l'auteur de RTD.

12
Xolv.io

À propos de l'utilisation de tinytest, vous voudrez peut-être jeter un œil à ces ressources utiles:

  1. Les bases sont expliquées dans cette capture d'écran: https://www.eventedmind.com/feed/meteor-testing-packages-with-tinytest

  2. Une fois que vous aurez compris l'idée, vous aurez besoin de la documentation de l'API publique pour tinytest. Pour l'instant, la seule documentation pour cela se trouve à la fin de la source du package tinytest: https://github.com/meteor/meteor/tree/devel/packages/tinytest =

  3. En outre, le screencast parle de test-helpers, vous voudrez peut-être consulter tous les assistants disponibles ici: https://github.com/meteor/meteor/tree/devel/packages/test-helpers Il y a souvent des documentation à l'intérieur de chaque fichier

  4. Creuser dans les tests existants des packages de météores fournira de nombreux exemples. Pour ce faire, vous pouvez rechercher Tinytest. ou test. dans le répertoire du package du code source de météore

6
William Ledoux

J'ai beaucoup utilisé cette page et essayé toutes les réponses, mais à partir du point de départ de mon débutant, je les ai trouvées assez déroutantes. Une fois que j'ai eu du mal, j'ai été déconcerté sur la façon de les réparer.

Cette solution est vraiment simple pour commencer, si elle n'est pas encore complètement documentée, donc je la recommande pour les gens comme moi qui veulent faire du TDD mais ne savent pas comment fonctionnent les tests en JavaScript et quelles bibliothèques se branchent sur quoi:

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

Pour info, j'ai constaté que je dois également utiliser le package Atmosphere du routeur pour créer une route '/ tests' pour exécuter et afficher les résultats des tests, car je ne voulais pas encombrer mon application chaque fois qu'il se charge.

6
pipedreambomb

Les tests deviennent un élément central de Meteor dans la prochaine version 1.3. La solution initiale est basée sur Mocha et Chai.

Les discussions originales sur la conception minimale viable peut être trouvée ici et les détails de la la première implémentation peut être trouvée ici .

MDG a produit les premiers éléments de la documentation du guide pour les tests qui peuvent être trouvés ici , et il y a quelques exemples de tests ici .

Voici un exemple de test de publication à partir du lien ci-dessus:

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

Je fais fonctionnel/intégration tests avec Meteor + Mocha dans le navigateur. J'ai quelque chose dans le sens de ce qui suit (en coffeescript pour une meilleure lisibilité):

Sur le client ...

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

... et sur le serveur:

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

Bien sûr, vous pouvez faire vos tests côté client nité de la même manière. Pour les tests d'intégration, il est agréable d'avoir toute l'infrastructure Meteor autour, cependant.

4
jerico

Comme Blackcout l'a dit, Velocity est le framework TDD officiel pour Meteor. Mais pour le moment, la page Web de velocity n'offre pas une bonne documentation. Je vous recommande donc de regarder:

3
Adrian Lopez

Une autre option, facilement accessible depuis la version 0.6.0, consiste à exécuter l'intégralité de votre application à partir de packages intelligents locaux, avec une quantité minimale de code en dehors des packages pour démarrer votre application (en invoquant éventuellement un package intelligent particulier qui est le fondement de votre application).

Vous pouvez ensuite tirer parti du Tinytest de Meteor, qui est idéal pour tester les applications Meteor.

2
matb33

Meteor + TheIntern

D'une manière ou d'une autre, j'ai réussi à tester l'application Meteor avec TheIntern.js.

Bien que ce soit selon mes besoins. Mais je pense quand même que cela peut conduire quelqu'un dans la bonne direction et je partage ce que j'ai fait pour résoudre ce problème .

Il existe une fonction execute qui nous permet d'exécuter du code JS à travers lequel nous pouvons accéder aux navigateurs window objet et donc Meteor également.

Vous voulez en savoir plus sur exécuter

C'est ainsi que mon test suite recherche Test fonctionnel

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

Pour en savoir plus, voici mon Gist

Remarque: je suis encore en phase très précoce avec cette solution. Je ne sais pas si je peux faire des tests complexes avec ça ou pas. Mais j'en suis assez confiant.

0
Harpreet Singh

La vitesse n'est pas encore mûre. Je suis confronté à des problèmes de setTimeout pour utiliser la vitesse. Pour les tests unitaires côté serveur, vous pouvez utiliser ce package .

C'est plus rapide que la vitesse. Velocity nécessite un temps énorme lorsque je teste n'importe quelle spécification avec une connexion. Avec le code Jasmine, nous pouvons tester n'importe quelle méthode et publication côté serveur.

0
Zahed

J'ai utilisé avec succès xolvio: concombre et vélocité pour faire mes tests. Fonctionne très bien et fonctionne en continu afin que vous puissiez toujours voir que vos tests réussissent.

0
Philip Beadle