このドキュメントのセクションでは、Sailsアプリケーションのテスト方法について説明します。SailsとNode.jsには、数え切れないほどのテストフレームワークとアサーションライブラリがあります。ニーズに合ったものを選択してください。
Sailsフレームワークには公式なテスト戦略はなく、このページはSailsコアチームメンバーによって徹底的に精査されていない、コミュニティ主導の共同ガイドです。わかりにくい点や誤りがある場合は、プルリクエストを送信してください。
テストスイートの例として、mochaを使用します。
npm install mocha --save-dev
テストケースの作成を開始する前に、test/
ディレクトリ構造を整理します。繰り返しますが、自動テストに関しては、いくつかの異なる組織的なアプローチを選択できます。この例では、次のように進めます。
./myApp
├── api/
├── assets/
├── ...
├── test/
│ ├── integration/
│ │ ├── controllers/
│ │ │ └── UserController.test.js
│ │ ├── models/
│ │ │ └── User.test.js
│ │ └── helpers/
| | └── ...
│ ├── fixtures/
| │ └── ...
│ ├── lifecycle.test.js
│ └── mocha.opts
├── ...
└── views/
このファイルは、テストの実行前後にコードを実行する場合(Sailsアプリケーションの起動と停止など)に役立ちます。モデルは起動時にWaterlineコレクションに変換されるため、テストする前にSailsアプリを起動する必要があります(これはコントローラーやアプリの他の部分にも当てはまるため、このファイルを最初に呼び出すようにしてください)。
var sails = require('sails');
// Before running any tests...
before(function(done) {
// Increase the Mocha timeout so that Sails has enough time to lift, even if you have a bunch of assets.
this.timeout(5000);
sails.lift({
// Your Sails app's configuration files will be loaded automatically,
// but you can also specify any other special overrides here for testing purposes.
// For example, we might want to skip the Grunt hook,
// and disable all logs except errors and warnings:
hooks: { grunt: false },
log: { level: 'warn' },
}, function(err) {
if (err) { return done(err); }
// here you can load fixtures, etc.
// (for example, you might want to create some records in the database)
return done();
});
});
// After all tests have finished...
after(function(done) {
// here you can clear fixtures, etc.
// (e.g. you might want to destroy the records you created above)
sails.lower(done);
});
このファイルはオプションです。カスタムMocha設定を指定するためのコマンドラインオプションの代替として使用できます。
注目すべきカスタマイズオプションの1つはタイムアウトです。Mochaのデフォルトのタイムアウトは2秒ですが、ほとんどのテストケースでは十分ですが、テストでSailsを起動および停止する頻度によっては短すぎる場合があります。Sailsが最初のテストを完了するのに間に合うように起動するには、mocha.optsでタイムアウト値を大きくする必要があるかもしれません。
--timeout 10000
注意:CoffeeScriptのようなトランスパイルされた言語(
.js
ファイルの代わりに.coffee
ファイル)でテストを記述している場合は、それに応じてMochaを構成するための追加の手順が必要です。たとえば、mocha.opts
に次の行を追加できます。--require coffee-script/register --compilers coffee:coffee-script/register
TypeScriptを使用する場合も、基本的に同じアプローチですが、
--require ts-node/register
を使用する必要があります。
ディレクトリを準備したら、統合テストの作成を開始できます。
// ./test/integration/models/User.test.js
var util = require('util');
describe('User (model)', function() {
describe('#findBestStudents()', function() {
it('should return 5 users', function (done) {
User.findBestStudents()
.then(function(bestStudents) {
if (bestStudents.length !== 5) {
return done(new Error(
'Should return exactly 5 students -- the students '+
'from our test fixtures who are considered the "best". '+
'But instead, got: '+util.inspect(bestStudents, {depth:null})+''
));
}//-•
return done();
})
.catch(done);
});
});
});
バックエンドコードの最も基本的なテストには、HTTPリクエストを送信してレスポンスをチェックすることが含まれます。Supertestのような本格的なテストツールでも、request
やmp-http
のような純粋なユーティリティでも、assert
と組み合わせるなど、さまざまな方法があります。
Supertestを使ってみましょう。
npm install supertest --save-dev
Supertestの背後にある考え方は、特定のタイプのテスト、具体的には、SailsアプリにHTTPリクエストを送信してレスポンスをチェックするタイプのテストを構築するのに役立つ高レベルのツールを提供することです。
// test/integration/controllers/UserController.test.js
var supertest = require('supertest');
describe('UserController.login', function() {
describe('#login()', function() {
it('should redirect to /my/page', function (done) {
supertest(sails.hooks.http.app)
.post('/users/login')
.send({ name: 'test', password: 'test' })
.expect(302)
.expect('location','/my/page', done);
});
});
});
Mochaを使用してテストを実行するには、コマンドラインでmocha
を使用し、実行するテストを引数として渡す必要があります。次のように、残りのテストの前にlifecycle.test.jsを呼び出すようにしてください:mocha test/lifecycle.test.js test/integration/**/*.test.js
npm test
を使用してテストを実行するpackage.jsonファイルを変更して、上記で説明したMochaコマンドを入力する代わりにnpm test
を使用できます。これは、lifecycle.test.jsを呼び出す場合に特に役立ちます。
scripts辞書にtest
キーを追加し、その値として次を使用します:mocha test/lifecycle.test.js test/integration/**/*.test.js
。これは次のようになります。
"scripts": {
"start": "node app.js",
"debug": "node debug app.js",
"test": "node ./node_modules/mocha/bin/mocha test/lifecycle.test.js test/integration/**/*.test.js"
}
*
は、integration/
フォルダー内の.test.js
で終わるすべてのファイルに一致するために使用されるワイルドカードです。必要に応じて、代わりに*.spec.js
を検索するように変更できます。同様に、フォルダーには、1つではなく2つの*
を使用してワイルドカードを使用できます。
Sails v1以降、Sailsアプリはpackage.jsonファイルに
test
スクリプトがすでに生成されていますが、この例ではいくつかの変更を加える必要があります。既存のアプリをアップグレードする場合は、test
キーを手動で追加する必要がある場合があります。
ソースコードリポジトリにプッシュするたびにシステムに自動的にテストを実行させたい場合は、幸運です!多くの異なる継続的インテグレーションシステムがSails/Node.jsをサポートしているため、自由に選択できます。以下に、開始するためのいくつかの一般的な選択肢を示します。
上記のオプションはすべて、プロプライエタリアプリに対して月額料金を請求しますが、オープンソースの場合は無料です。Circle CIもプロプライエタリアプリには無料ですが、一度に2つのビルドに制限されています。Semaphoreも無料で、4倍の並列CI/CDジョブが可能です。
Webアプリケーションの負荷テストには、多数の商用オプションが存在します。ab
やJMeterのようなツールを使用しても、アプリのパフォーマンスについて妥当なアイデアを得ることができます。実際のトラフィックをシミュレートすることを忘れないでください。Sailsアプリを本番環境に対応させ、スケーラブルにするための詳細については、スケーラビリティを参照してください。追加のヘルプやより具体的な質問については、ここをクリックしてください。
ドポイントへの個々のリクエストのパフォーマンスと遅延よりも重要です。したがって、分離された1つのコードに焦点を当てるのではなく、基本から始めることをお勧めします。ほとんどのアプリでは、それで十分です。ただし、一部のユースケース(広告の配信や、計算量の多い機能を持つアプリなど)では、最初から個々のリクエストの遅延が重要になる場合があります。
特定のコードのパフォーマンスをテストしたり、特定のエンドポイントへの個々のリクエストの遅延をベンチマークしたりするための優れたオプションは、benchmark.jsです。これは、高分解能タイマーをサポートし、統計的に有意な結果を返す堅牢なライブラリであるだけでなく、Mochaともすぐに使用できます。