Développement piloté par les tests Meteor [fermé]

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

Je ne le vois mentionné nulle part dans la documentation ou la FAQ. Je ne vois aucun exemple ou quoi que ce soit de ce genre.

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 du genre:

• possible, pas de documentation, découvrez-le vous-même
• meteor n'est pas conçu de manière à ce que vous puissiez créer des applications testables
• c'est une fonctionnalité prévue
• etc

Mise à jour 3 : à partir de Meteor 1.3, meteor comprend un guide de test avec des instructions étape par étape pour les tests unitaires, d'intégration, d'acceptation et de charge.

Mise à jour 2 : depuis le 9 novembre 2015, Velocity n'est plus maintenu . Xolv.io concentre ses efforts sur Chimp , et le groupe de développement Meteor doit choisir un cadre de test officiel .

Mise à jour : Velocity est la solution de test officielle de Meteor à partir de la version 0.8.1.

Peu de choses ont été écrites sur les tests automatisés avec Meteor pour le moment. J'attends de la communauté Meteor qu'elle 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 changent encore rapidement.

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

Pour mon projet Meteor, j'exécute 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 vous 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 placer vos tests dans le dossier "tests" afin que Meteor ne tente 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 pour un Makefile.

Vos modèles Meteor auront besoin d'un peu de modification pour s'exposer à Mocha, ce qui 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 dans différents fichiers les uns aux autres, mais les applications Node ordinaires, comme Mocha, ne le font pas. Pour rendre nos modèles testables par Mocha, exportez chaque 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!

Salut à tous, checkout laika - le tout nouveau cadre de test pour meteor http://arunoda.github.io/laika/

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

• Voir quelques exemples de laika ici
• Voir ici pour les fonctionnalités
• Voir le concept derrière laika
• Voir le référentiel Github

Avertissement: je suis l'auteur de Laika.

Je me rends compte que cette question a déjà reçu une réponse, 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 du développement de packages, à la fois en implémentant un package pour meteor core, ainsi que pour l' atmosphère .

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

1. Comment exécuter toute la suite de tests meteor?
2. Comment écrire et exécuter des tests pour des packages intelligents individuels ?
3. Comment écrire et exécuter des tests pour sa propre application?

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

J'ai parlé et j'ai commencé à collaborer avec Naomi Seyfer (@sixolet) au sein de l' équipe principale de météorite pour aider à obtenir des réponses définitives à toutes ces questions dans la documentation.

J'avais soumis une demande de tirage initiale adressant 1 et 2 à meteor core: https://github.com/meteor/meteor/pull/573 .

J'avais également récemment répondu à cette question: comment exécutez-vous les tests de météorites?

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

En ce qui concerne le bonus, 4, je suggérerais d'utiliser au moins circleci.com pour faire une intégration continue de 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 mocha, à peu près comme @Blackcoat l'avait décrit.

Pour une intégration continue sur meteor core et des packages intelligents, Naomi Seyfer et moi discutons avec le fondateur de circleci pour voir si nous pouvons implémenter quelque chose de génial à court terme.

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 nouvelle car Velocity est en cours de développement intensif. Vous pouvez trouver plus d'informations sur le repo Velocity Github , la page d'accueil Velocity et The Meteor Testing Manual (contenu payant)

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

Consultez RDT, un cadre de test complet pour Meteor ici rtd.xolv.io . Il prend en charge Jasmine / Mocha / custom et fonctionne à la fois avec le JS ordinaire et le café. Il comprend également une couverture de test qui combine la 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 cela pourra aider. Avertissement: je suis l'auteur de RTD.

J'ai beaucoup utilisé cette page et essayé toutes les réponses, mais à partir de mon début, je les ai trouvées assez déroutantes. Une fois que j'ai eu des problèmes, j'ai été perplexe quant à la façon de les résoudre.

Cette solution est très simple à utiliser, si elle n'est pas encore entièrement documentée, je la recommande donc aux personnes comme moi qui veulent faire du TDD mais ne savent pas comment les tests en JavaScript fonctionnent et quelles bibliothèques se connectent à quoi:

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

Pour info, j'ai trouvé que je devais é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 qu'il encombre mon application à chaque fois qu'elle se charge.

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

1. Les bases sont expliquées dans ce screencast: https://www.eventedmind.com/feed/meteor-testing-packages-with-tinytest

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

3. De plus, le screencast en parle test-helpers, vous voudrez peut-être jeter un coup d'œil à tous les helpers disponibles ici: https://github.com/meteor/meteor/tree/devel/packages/test-helpers Il y a souvent de la documentation à l'intérieur de chacun fichier

4. Creuser dans les tests existants des paquets de meteor fournira de nombreux exemples. Une façon de faire est de faire une recherche pour Tinytest.ou test.dans le répertoire du package du code source de meteor

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 peuvent être trouvées ici et les détails de la première implémentation peuvent être trouvés ici .

MDG a produit les bases initiales de la documentation du guide pour les tests qui peut être trouvée 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();
    });
  });

Je fais des tests fonctionnels / d'intégration avec Meteor + Mocha dans le navigateur. J'ai quelque chose du genre 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="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()

... et sur le serveur:

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

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

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

• Concept derrière la vitesse
• Tutoriel étape par étape
• Et spécialement les exemples officiels

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

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

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

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 mon besoin. 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 executefonction qui nous permet d'exécuter du code JS à partir duquel nous pouvons accéder aux windowobjets du navigateur et donc Meteoraussi.

Vous voulez en savoir plus sur exécuter

Voici comment mes test suiterecherches sur les tests fonctionnels

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, c'est mon sens

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 cela ou non. Mais j'en suis assez confiant.

La vitesse n'est pas encore mature. 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. La vitesse 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.