流星でテスト駆動開発を行う方法がわかりません。
ドキュメントやFAQのどこにも言及されていません。例などは見当たりません。
一部のパッケージがTinytestを使用していることがわかります。
開発者からの回答が必要です。これに関するロードマップは何ですか。次のようなもの:
- 可能です、ドキュメントはありません、自分でそれを理解してください
- meteorは、テスト可能なアプリを作成できるように構築されていません
- これは計画された機能です
- 等
アップデート3:Meteor 1.3以降、meteorには、ユニット、統合、受け入れ、および負荷テストのステップバイステップの説明が記載されたテストガイドが含まれています。
アップデート2:2015年11月9日をもって、Velocityは維持されなくなりました。Xolv.ioはチンパンジーに力を注いでおり、MeteorDevelopmentGroupは公式のテストフレームワークを選択する必要があります。
更新:Velocityは、0.8.1現在のMeteorの公式テストソリューションです。
現時点では、Meteorを使用した自動テストについてはあまり書かれていません。Meteorコミュニティは、公式ドキュメントで何かを確立する前に、テストのベストプラクティスを進化させることを期待しています。結局のところ、Meteorは今週0.5に達しました、そして物事はまだ急速に変化しています。
良いニュース:MeteorでNode.jsテストツールを使用できます。
Meteorプロジェクトでは、アサーションにChaiを使用してMochaで単体テストを実行します。Chaiの完全な機能セットが必要ない場合は、代わりにshould.jsを使用することをお勧めします。現時点では単体テストしかありませんが、Mochaとの統合テストを作成することもできます。
Meteorがテストを実行しようとしないように、必ず「tests」フォルダーにテストを配置してください。
Mochaは、Meteorプロジェクト用に選択したスクリプト言語であるCoffeeScriptをサポートしています。これは、Mochaテストを実行するためのタスクを含むCakefileのサンプルです。MeteorでJSを使用している場合は、Makefile用にコマンドを自由に調整してください。
Meteorモデルは、Mochaに公開するために少し変更する必要があります。これには、Node.jsがどのように機能するかについての知識が必要です。各Node.jsファイルは、独自のスコープ内で実行されていると考えてください。Meteorは、異なるファイル内のオブジェクトを相互に自動的に公開しますが、Mochaなどの通常のNodeアプリケーションはこれを行いません。モデルをMochaでテスト可能にするには、次のCoffeeScriptパターンを使用して各Meteorモデルをエクスポートします。
# 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?
...そして、Mochaテストの上部で、テストするモデルをインポートします。
# 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/
サーバーとクライアントの両方を一度にテストできます。
免責事項:私はライカの作者です。
私はこの質問がすでに回答されていることを認識していますが、これは、上記のコンテキストを提供する追加の回答の形で、もう少しコンテキストを使用できると思います。
私は、meteorコアと雰囲気の両方のパッケージを実装することにより、meteorを使用したアプリ開発とパッケージ開発を行ってきました。
あなたの質問は実際には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が説明したように、モカで単体テストを実行するために、coffeescriptで記述されたテストを正常に取得したプロジェクトがあります。
流星コアとスマートパッケージの継続的インテグレーションのために、Naomi Seyferと私はcircleciの創設者とチャットして、近いうちに素晴らしいものを実装できるかどうかを確認しています。
RTDは廃止され、Meteor1.0の公式テストフレームワークであるVelocityに置き換えられました。Velocityは開発が進んでいるため、ドキュメントはまだ比較的新しいものです。Velocity Githubリポジトリ、Velocityホームページ、およびMeteor Testing Manual(有料コンテンツ)で詳細情報を見つけることができます。
免責事項:私はVelocityのコアチームメンバーの1人であり、本の著者です。
Meteorの完全なテストフレームワークであるRTDをここrtd.xolv.ioで確認してください。Jasmine / Mocha / customをサポートし、プレーンJSとコーヒーの両方で動作します。ユニット/サーバー/クライアントカバレッジを組み合わせたテストカバレッジも含まれます。
そしてここにサンプルプロジェクト
Meteorを使用した単体テストについて説明するブログはこちら
ここでSeleniumWebdriverJSとMeteorを使用したe2e受け入れテストアプローチ
お役に立てば幸いです。免責事項:私はRTDの作者です。
私はこのページをよく使ってすべての答えを試しましたが、初心者の最初から、かなり混乱していることに気づきました。困ったときは、どうやって直せばいいのか悩みました。
このソリューションは、まだ完全に文書化されていなくても、始めるのは本当に簡単です。したがって、TDDを実行したいが、JavaScriptでのテストがどのように機能し、どのライブラリが何にプラグインするかわからない私のような人々に推奨します。
https://github.com/mad-eye/meteor-mocha-web
参考までに、アプリが読み込まれるたびにアプリが乱雑にならないように、ルーターAtmosphereパッケージを使用して「/ tests」ルートを作成し、テストの結果を実行して表示する必要があることがわかりました。
tinytestの使用法については、これらの便利なリソースを確認することをお勧めします。
基本はこのスクリーンキャストで説明されています: https ://www.eventedmind.com/feed/meteor-testing-packages-with-tinytest
アイデアを理解したら、のパブリックAPIドキュメントが必要になりますtinytest
。今のところ、そのための唯一のドキュメントは、tinytest
パッケージのソースの最後にあります:https ://github.com/meteor/meteor/tree/devel/packages/tinytest
また、スクリーンキャストtest-helpers
では、利用可能なすべてのヘルパーをここで確認することをお勧めします:
https ://github.com/meteor/meteor/tree/devel/packages/test-helpers
多くの場合、それぞれの中にいくつかのドキュメントがありますファイル
流星のパッケージの既存のテストを掘り下げると、多くの例が得られます。これを行う1つの方法は、meteorのソースコードのパッケージディレクトリを検索するTinytest.
ことです。test.
テストは、次の1.3リリースでMeteorのコア部分になります。最初の解決策は、モカとチャイに基づいています。
最小実行可能設計の元の説明はここにあり、最初の実装の詳細はここにあります。
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="/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を使用してテストを行うことに成功しました。非常にうまく機能し、継続的に実行されるため、テストに合格していることを常に確認できます。
Meteor + TheIntern
どういうわけか私はTheIntern.jsでMeteorアプリケーションをテストすることができました。
それは私の必要に応じていますが。しかし、それでも私はそれが誰かを正しい方向に導くかもしれないと思います、そして私はこの問題を解決するために私がしたことを共有しています。
ブラウザオブジェクトにexecute
アクセスできる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コードを使用すると、サーバー側のメソッドとパブリケーションをテストできます。