流星テスト駆動開発[終了]

meteorでテスト駆動開発を行う方法がわかりません。

ドキュメントやFAQのどこにも記載されていません。例などは見当たりません。

一部のパッケージがTinytestを使用しているようです。

開発者からの応答が必要です。これに関するロードマップは何ですか。以下に沿ったもの：

• 可能、ドキュメントなし、自分で理解する
• 流星は、テスト可能なアプリを作成できるように構築されていません
• これは計画された機能です
• 等

更新3：Meteor 1.3以降、meteorには、ユニット、統合、受け入れ、および負荷テストの手順を追ったテストガイドが含まれています。

アップデート2：2015年11月9日以降、Velocityはメンテナンスされなくなりました。Xolv.ioは彼らの努力をチンパンジーに集中しており、Meteor Development Groupは公式のテストフレームワークを選択する必要があります。

更新：Velocityは、0.8.1時点でのMeteorの公式テストソリューションです。

現時点では、Meteorを使用した自動テストについてはあまり書かれていません。Meteorコミュニティは、公式ドキュメントで何かを確立する前に、テストのベストプラクティスを進化させることを期待しています。結局、Meteorは今週0.5に達し、物事はまだ急速に変化しています。

朗報です。Node.jsテストツールをMeteorで使用できます。

私のMeteorプロジェクトでは、アサーションにChaiを使用してモカでユニットテストを実行します。Chaiの完全な機能セットが必要ない場合は、代わりにshould.jsを使用することをお勧めします。現時点では単体テストしかありませんが、Mochaとの統合テストも作成できます。

Meteorがテストを実行しないように、必ず「tests」フォルダーにテストを配置してください。

Mochaは、Meteorプロジェクト用に選択したスクリプト言語であるCoffeeScriptをサポートしています。以下は、Mochaテストを実行するためのタスクを含むサンプルCakefileです。JSをMeteorで使用している場合は、Makefileのコマンドを自由に変更してください。

Meteorモデルは、Mochaに公開するために少し変更する必要があります。これには、Node.jsの動作に関するある程度の知識が必要です。各Node.jsファイルは、独自のスコープ内で実行されていると考えてください。Meteorは自動的に異なるファイル内のオブジェクトを相互に公開しますが、Mochaなどの通常のNodeアプリケーションはこれを行いません。モデルをMochaでテスト可能にするには、各Meteorモデルを次の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?

...そしてモカテストの上部に、テストするモデルをインポートします。

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

これで、Meteorプロジェクトで単体テストの作成と実行を開始できます。

こんにちは、すべてのチェックアウトライカ -流星http://arunoda.github.io/laika/のまったく新しいテストフレームワーク

サーバーとクライアントの両方を一度にテストできます。

• ここにいくつかのライカの例を見る
• 機能についてはこちらをご覧ください
• ライカのコンセプトを見る
• Githubリポジトリを参照

免責事項：私はライカの作者です。

この質問にはすでに回答していることを理解していますが、これには、コンテキストを提供する追加の回答という形で、もう少しコンテキストを使用できると思います。

meteorコアと大気の両方にパッケージを実装することにより、meteorを使用したアプリ開発とパッケージ開発の両方を行ってきました。

あなたの質問は、実際には3つの部分からなる質問のように思えます。

1. 流星テストスイート全体をどのように実行しますか？
2. 個々のスマートパッケージのテストを作成して実行するにはどうすればよいですか？
3. 自分のアプリケーションのテストを作成して実行するにはどうすればよいですか？

また、どこかにボーナスの質問があるようにも聞こえます。4。1、2、3の継続的インテグレーションをどのように実装できますか？

私は流星コアチームのNaomi Seyfer（@sixolet）と話し合って共同作業を開始し、これらすべての質問に対する明確な回答をドキュメントにまとめる手助けをしています。

1と2に対応する最初のプルリクエストをMeteorコアに送信しました：https : //github.com/meteor/meteor/pull/573。

私は最近この質問にも答えました： どのようにして流星テストを実行しますか？

@Blackcoatは確実に上記の3に回答したと思います。

おまけの4については、少なくとも独自のアプリを継続的に統合するためにcircleci.comを使用することをお勧めします。彼らは現在、@ Blackcoatが説明したユースケースをサポートしています。@Blackcoatが述べたように、私はmochaを使用して単体テストを実行するためのコーヒースクリプトで書かれたテストを正常に取得したプロジェクトを持っています。

meteorコアとスマートパッケージの継続的な統合について、Naomi Seyferと私は、circleciの創設者とチャットして、近い将来に素晴らしいものを実装できるかどうかを確認しています。

RTDは非推奨となり、Meteor 1.0の公式テストフレームワークであるVelocityに置き換えられました。Velocityは開発が進んでいるため、ドキュメントはまだ比較的新しいものです。Velocity Githubリポジトリ、Velocityホームページ、およびMeteor Testing Manual（有料コンテンツ）で詳細を確認できます。

免責事項：私はVelocityのコアチームメンバーの1人であり、本の著者です。

Meteorの完全なテストフレームワークであるRTDについては、こちらのrtd.xolv.ioをご覧ください。ジャスミン/モカ/カスタムをサポートし、プレーンなJSとコーヒーの両方で動作します。ユニット/サーバー/クライアントカバレッジを組み合わせたテストカバレッジも含まれます。

そしてここにサンプルプロジェクト

Meteorを使った単体テストを説明するブログはこちら

Selenium WebdriverJSとMeteorを使用したe2e受け入れテストアプローチはこちら

お役に立てば幸いです。免責事項：私はRTDの作成者です。

私はこのページをたくさん使ってすべての答えを試しましたが、初心者の出発点から、それらはかなり混乱していることに気付きました。何か問題があったら、どうやって直せばいいのか迷いました。

このソリューションは、まだ完全に文書化されていない場合でも、開始するのは非常に簡単なので、TDDを実行したいが、JavaScriptでのテストがどのように機能し、どのライブラリが何にプラグインするかがわからない、私のような人にはお勧めします。

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

参考までに、「/ tests」ルートを作成してテストの結果を表示するには、ルーターのAtmosphereパッケージを使用する必要があることもわかりました。アプリが読み込まれるたびにアプリが煩雑になりたくないからです。

tinytestの使用法については、これらの便利なリソースをご覧ください。

1. 基本はこのスクリーンキャストで説明されています：https : //www.eventedmind.com/feed/meteor-testing-packages-with-tinytest

2. アイデアを理解したら、の公開APIドキュメントが必要になりますtinytest。今のところ、そのための唯一のドキュメントは、tinytestパッケージのソースの最後にあります：https : //github.com/meteor/meteor/tree/devel/packages/tinytest

3. また、スクリーンキャストはについて話しtest-helpersます、あなたはここで利用可能なすべてのヘルパーを見てみたいかもしれません：https : //github.com/meteor/meteor/tree/devel/packages/test-helpers それぞれの中にいくつかのドキュメントがあるファイル

4. 流星のパッケージの既存のテストを掘り下げると、多くの例が提供されます。これを行う1つの方法は、流星のソースコードのパッケージディレクトリ内Tinytest.またはtest.パッケージディレクトリ内を検索することです。

テストは、今後の1.3リリースでMeteorの中核となる部分です。最初のソリューションは、MochaとChaiに基づいています。

最小実行可能な設計の元の議論はここにあり、最初の実装の詳細はここにあります。

MDGは、テスト用のガイドドキュメントの最初の骨をここで見つけることができ、ここにいくつかのテスト例があります。

これは、上記のリンクからの公開テストの例です。

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

ブラウザでMeteor + Mochaを使用して機能/統合テストを行っています。私は次の線に沿って何かを持っています（読みやすくするためにコーヒースクリプトで）：

クライアントで...

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

...そしてサーバー上：

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

もちろん、同じ方法でクライアント側のユニットテストを行うことができます。ただし、統合テストの場合は、Meteorインフラストラクチャをすべて用意しておくと便利です。

Blackcoutが言ったように、Velocity は Meteorの公式TDDフレームワークです。しかし、現時点では、velocityのWebページは適切なドキュメントを提供していません。だから私はあなたが見ることをお勧めします：

• 速度の背後にある概念
• ステップバイステップのチュートリアル
• そして特に公式の例

0.6.0以降で簡単に利用できる別のオプションは、ローカルスマートパッケージからアプリ全体を実行することです。パッケージの外側に最小限のコードでアプリを起動します（おそらく、アプリケーションの基盤である特定のスマートパッケージを呼び出します）。アプリ）。

その後、MeteorのTinytestを活用できます。これは、Meteorアプリのテストに最適です。

私はxolvio：cucumberとvelocityを使用してテストを成功させています。非常にうまく機能し、継続的に実行されるため、テストが成功していることを常に確認できます。

流星+インターン

どういうわけか私はTheIntern.jsでMeteorアプリケーションをテストすることができました。

それは私の必要に応じてですが。しかし、それでも誰かを正しい方向に導く可能性があると思います。この問題を解決するために私がしたことを共有しています。

あるexecute私たちは、ブラウザがアクセスできるthorugh JSコードを実行することを可能にする機能windowことを目的とMeteorもに。

実行についてもっと知りたい

これが機能テストの私のtest suite見方です

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

もっと知るために、これは私の要点です

注：このソリューションはまだ非常に初期の段階です。これで複雑なテストができるかどうかわかりません。しかし、私はそれについてはかなり自信があります。

速度はまだ成熟していません。速度を使用するためにsetTimeoutの問題に直面しています。サーバー側のユニットテストでは、このパッケージを使用できます。

速度よりも高速です。ログインでスペックをテストするとき、Velocityは非常に長い時間を必要とします。Jasmineコードを使用して、サーバー側のメソッドと公開をテストできます。