流星でテスト駆動開発を行う方法がわかりません。
ドキュメントやFAQのどこにも言及されていません。例やそのようなものは見当たりません。
いくつかのパッケージがTinytestを使用していることがわかります。
開発者からの応答が必要です。これに関するロードマップは何ですか。以下の線に沿ったもの:
更新3:Meteor 1.3以降、meteorには テストガイド が含まれており、ユニット、統合、受け入れ、および負荷テスト。
更新2:2015年11月9日現在、 速度は維持されていません 。 Xolv.ioは、 Chimp と、 流星開発グループが公式のテストフレームワークを選択する必要がある に注力しています。
更新: 速度 は 流星の公式テストソリューション 0.8.1の時点で.
現時点では、Meteorを使用した自動テストについてはあまり書かれていません。 Meteorコミュニティは、公式ドキュメントで何かを確立する前にテストのベストプラクティスを進化させることを期待しています。結局のところ、Meteorは今週0.5に達し、物事は依然として急速に変化しています。
朗報:Meteorで Node.jsテストツール を使用できます。
Meteorプロジェクトでは、アサーションに Mocha を使用して Chai を使用して単体テストを実行します。 Chaiの完全な機能セットが必要ない場合は、代わりに should.js を使用することをお勧めします。 Mochaで統合テストを作成することもできますが、現時点ではユニットテストしかありません。
Meteorがテストの実行を試行しないように、必ず テストを「tests」フォルダーに配置してください にしてください。
Mochaは CoffeeScript をサポートします。これは、Meteorプロジェクト用のスクリプト言語の選択です。以下に、Mochaテストを実行するためのタスクを含む サンプルCakefile を示します。 MeteorでJSを使用している場合は、Makefileのコマンドを自由に調整してください。
Meteorモデルは、Mochaに公開するために少し変更する必要があります。これには、Node.jsの動作方法に関するある程度の知識が必要です。各Node.jsファイルは、独自のスコープ内で実行されると考えてください。 Meteorは異なるファイルのオブジェクトを自動的に相互に公開しますが、通常のNode Mochaなどのアプリケーションはこれを行いません。Mochaでモデルをテスト可能にするには、 export each次の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?
...そして、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プロジェクトで単体テストの作成と実行を開始できます!
こんにちはすべてのチェックアウト laika -流星のまったく新しいテストフレームワーク http://arunoda.github.io/laika/
サーバーとクライアントの両方を一度にテストできます。
免責事項:私はライカの著者です。
この質問はすでに回答されていることを理解していますが、このコンテキストを提供する追加の回答の形で、さらに多くのコンテキストを使用できると思います。
Meteorコアと、 atmosphere の両方のパッケージを実装することにより、Meteorを使用したアプリ開発とパッケージ開発を行ってきました。
あなたの質問は、実際には3つの部分からなる質問のようです。
そして、どこかにボーナスの質問があるかもしれません:4. 1、2、3の継続的な統合をどのように実装できますか?
流星 コアチーム で ナオミセイファー(@sixolet) と話し合って共同作業を開始し、すべてに対する明確な回答を得ましたこれらの質問のドキュメントに。
1と2をアドレス指定する最初のプルリクエストをmeteorコアに送信しました: https://github.com/meteor/meteor/pull/573 。
私は最近この質問にも答えました: 流星テストをどのように実行しますか?
@Blackcoatは上記の3に間違いなく答えていると思います。
ボーナスについては、4、 circleci.com を使用して、少なくとも独自のアプリの継続的な統合を行うことをお勧めします。現在、@ Blackcoatが説明したユースケースをサポートしています。 @blackcoatで説明したように、mochaでユニットテストを実行するためにcoffeescriptで記述されたテストを正常に取得したプロジェクトがあります。
Meteorコアとスマートパッケージの継続的な統合のために、Naomi Seyferと私はcircleciの創設者とおしゃべりして、近いうちに素晴らしいものを実装できるかどうかを確認しています。
RTDは非推奨となり、Meteor 1.0の公式テストフレームワークであるVelocityに置き換えられました。 Velocityが開発中のため、ドキュメントはまだ比較的新しいものです。 Velocity Github repo 、 Velocity Homepage および The Meteor Testing Manual (有料コンテンツ)に関する詳細情報を見つけることができます。
免責事項:私はVelocityのコアチームメンバーの一人であり、本の著者でもあります。
Meteorの完全なテストフレームワークであるRTDについては、こちらをご覧ください rtd.xolv.io 。 Jasmine/Mocha/customをサポートし、プレーンJSとコーヒーの両方で動作します。ユニット/サーバー/クライアントカバレッジを組み合わせたテストカバレッジも含まれます。
そしてサンプルプロジェクト here
Meteorを使用した単体テストを説明するブログ here
Selenium WebdriverJSとMeteorを使用したe2e受け入れテストアプローチ here
お役に立てば幸いです。免責事項:私はRTDの著者です。
Tinytestの使用法については、これらの便利なリソースをご覧ください。
このスクリーンキャストで基本を説明します。 https://www.eventedmind.com/feed/meteor-testing-packages-with-tinytest
アイデアを理解したら、tinytest
の公開APIドキュメントが必要になります。今のところ、そのための唯一のドキュメントはtinytest
パッケージのソースの最後にあります: https://github.com/meteor/meteor/tree/devel/packages/tinytest =
また、スクリーンキャストではtest-helpers
について説明しています。利用可能なすべてのヘルパーについては、こちらをご覧ください: https://github.com/meteor/meteor/tree/devel/packages/test -helpers 各ファイル内にいくつかのドキュメントがあります
Meteorのパッケージの既存のテストを掘り下げると、多くの例が提供されます。これを行う1つの方法は、meteorのソースコードのパッケージディレクトリでTinytest.
またはtest.
を検索することです。
私はこのページを頻繁に使用し、すべての答えを試しましたが、初心者の出発点から、それらは非常に混乱していることがわかりました。トラブルが発生すると、それらを修正する方法について混乱しました。
このソリューションは、まだ完全に文書化されていない場合でも、始めるのは非常に簡単です。したがって、TDDを行いたいが、JavaScriptでのテストがどのように機能し、どのライブラリが何にプラグインされるのかわからない人にはお勧めします:
https://github.com/mad-eye/meteor-mocha-web
参考までに、 router Atmosphere package を使用して '/ tests'ルートを作成し、テストの結果を実行して表示する必要があることがわかりました。ロードするたびに。
テストは、次の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を使用してfunctional/integrationテストを実行しています。私は次の行に沿って何かを持っています(読みやすくするためにcoffeescriptで):
クライアント上で...
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.
もちろん、クライアント側nitを同じ方法でテストできます。ただし、統合テストの場合は、すべてのMeteorインフラストラクチャを使用するのがよいでしょう。
Blackcoutが言ったように、Velocity 公式TDDフレームワーク Meteor用。しかし、現時点では、velocityのWebページは優れたドキュメントを提供していません。だから私はあなたが見ることをお勧めします:
0.6.0から簡単に利用できる別のオプションは、ローカルスマートパッケージからアプリ全体を実行し、パッケージの外部で最低限のコードを実行してアプリを起動することです(おそらく、特定のスマートパッケージを呼び出して、アプリ)。
その後、MeteorのTinytestを活用できます。これは、Meteorアプリのテストに最適です。
流星+ TheIntern
どういうわけか、TheIntern.jsでMeteorアプリケーションをテストすることができました。
それは私のニーズによるものです。しかし、それでも誰かを正しい方向に導くかもしれないと思い、私はこの問題を解決するためにしたことを共有しています。
ブラウザーのexecute
オブジェクト、したがってwindow
にもアクセスできるJSコードを実行できるMeteor
関数があります。
execute についてもっと知りたい
これが私の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コードを使用すると、サーバー側のメソッドとパブリケーションをテストできます。
私はテストを行うためにxolvio:cucumberとvelocityを使用することに成功しています。本当にうまく機能し、継続的に実行されるため、テストに合格していることを常に確認できます。